Problems with sqlite support with 1.4.8: no such table: uniqueid_temp

[Rich]

On 2008.02.26. 14:39, Jeff Mitchell wrote:
...
> So here's why you get those _temp errors.
> 
> You said you were doing full rescans.  When the collection scanner is doing an 
> incremental scan it creates temporary tables populated with old information; 
> then it drops the normal tables, scans, and copies the info from the temp 
> tables back (I think I have that sequence right).  However, when doing a full 
> rescan it drops all tables and just scans directly in, it doesn't create 

does it really drop tables ? i hope it doesn't, because we tell people 
to do full rescans all the time and they sort of don't come back 
complaining about lost statistics...

> temporary tables.  So when the unique ID for a URL is wanted, the function 
> checks to see if scanning is currently happening.  If so, it defaults to 
> looking up the UID in the temp table (because the scan isn't yet complete).  
> If it gets no value back, it then checks the normal table.  Since Amarok 
> prints out these errors from the database what you're seeing is simply a 
> result of checking the temp table first, which may not exist.  It's a totally 
> harmless error.  The reason it checks the temp tables first is because it if 
> you have information about a unique ID in both locations it defaults to the 
> old information in case they've not yet gotten merged.  That was actually 

hmm. but in my case, it is a full first scan, there are no tables before 
that.
i don't see any reason why should amarok query uid at all (i don't have 
any tracks in the playlist, i am not adding any tracks to playlist etc).

> based on an old architecture of AFT and is probably not relevant 
> anymore...rethinking the issue, I don't see why it couldn't be flipped.  
> Although you could still see the errors if you're scanning and the new 
> database tables do not yet have that URL value in them (so a better way is if 
> you know a backend-agnostic query to find out whether or not a table 
> exists...).
...
-- 
  Rich