> far more quickly using SQL and a second table Not sure this is so in my particular case as the age to ageband conversion is variable, so the lookup table will need to be created and populated every time. I suppose common ones such as the 0 to 10, 11 to 20 etc. could be kept for future use, but that would make it all lot more complex coding-wise. Will have a look though at the speed of creating a temp table in memory and converting that way, but my guess is that it is slower.
RBS On Thu, Nov 22, 2012 at 12:58 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 22 Nov 2012, at 10:47am, Bart Smissaert <bart.smissa...@gmail.com> wrote: > >> Ignore this e-mail, it was a simple mistake from my side and nil to do >> with SQLite. > > It takes a big man to admit a mistake. Thanks for saving us the time of > figuring out your problem. > > By the way ... your original question talks about a problem which can be > solved far more quickly using SQL and a second table. Put a table into your > database which does the conversion for you: > > lowerLimit descriptionText > 0 0 - 10 > 11 11 - 20 > ... > 91 91 - 100 > 101 over 100 > > And create an index on lowerLimit. Then look up the description you want > using > > SELECT descriptionText FROM ageDescriptions WHERE lowerLimit <= [myvar] ORDER > BY lowerLimit DESC LIMIT 1 > > You will always get get one row which has the description you want. You can > do the lookup either before you do your INSERT (to put the description into > the database) or the modern way would be to do the lookup only when you > actually need to know the age band, probably just before you show the data on > the display. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
