Leaderboard

For those of us that can't/won't follow Twitter - http://downforeveryo...e.com/lavag.org

I've never noticed this before. Is it something that this site provides or does Google determine what shows up there?

Hi asbo, Thanks for replying again. Well I took your advice and Googled as you suggested, and it turned up trumps! I found a cracking little site that explained all about ADO and Excel in terms that even I could understand. It even had simple examples albethem text based, though it was simple to follow. I hadn't realised that Excel was a database, or at least via ADO could be treated as one. I only had to slightly tweak the SQL stuff in my ADO MS Access VIs that I'd written to get them to work with Excel. I think I might change those to handle both Access and Excel based on the target's file extension perhaps. Incidentally, I did a little experiment. I created a simple three-column two-row Worksheet in Excel by hand. I ran my ActiveX Excel Worksheet Reader VI on it and it took 2-3 seconds to return the 2D array. I tweaked my ADO MS Access table reader appropriately (with my newly gained knowledge!!!) then ran that on the Excel Worksheet and it returned pretty much instantaneously. So there you have it. ADO it is for me from now on. Obviously there is some overhead in in ActiveX. A guy I know who does databases for a living tells me the ActiveX layer sits above ADO??? A bit beyond me but I'm happy I'm moving forward now. Thanks so much to LAVA and to you asbo. I just learn so much cool stuff here it's untrue. Regards.

He's LAVAs mascot

fsynch is only used on unix-like OSs (read linux, Mac). Under windows "FlushFileBuffers" is used. It also states at the end of the paragraph that "These are hardware and/or operating system bugs that SQLite is unable to defend against. And again in Things that can go wrong section 9.4 it states: "Corrupt data might also be introduced into an SQLite database by bugs in the operating system or disk controller; especially bugs triggered by a power failure. There is nothing SQLite can do to defend against these kinds of problems." Where locking is "broken" (multiple simultaneous writes causing corruption) it seems to be referring to network file systems. In this scenario the websire states: "You are advised to avoid using SQLite on a network filesystem in the first place" The main issue seems to be cantered around old consumer grade IDE drives. I remember a long time ago reports about something like this. I haven't, however, read any articles about SATA drives having similar problems (much moe prevalent nowadays). But synchronous mode seems to be an attempt to "wait" a few disk revs in the hope that the data in the cache is finally written to a drive if its still in the drives internal write cache. (Still. Not a guarantee). And I think probably not relevant with many modern hard-disks and OSs (windows at least). Additionally. Putting SQLite (as a single subsystem) through our risk assessment procedure reveals a very low risk. My view is that if the data is really that important, then classical techniques should also be employed (frequent back-ups, UPS, redundancy etc). You can. You just compose them as a string and use the transaction Query". That is its purpose. Although in the "Speed example" it's only used for inserts. It can also be used for "Selects, updates, deletes etc". The API is split into 2 levels. 1. The top level (polymorphic) VIs which are designed as "fire-and-forget", easy DB manipulation, that can be placed anywhere in an application as a single module. 2. Low level VIs which have much of the commonly used functionality of SQLite to enable people to "roll-your-own". You can (for example) just open a DB and execute multiple inserts and queries before closing in exactly the same way as yours and other implementations do (this is what "query by ref" is for and is synonymous to the SQLite "exec" function).. In benchmarks I ran initially, there is little impact in opening and closing on each query (1-15 us). The predominant time is the collation of query results (for selects) and commit of inserts. But it gives the modularity and encapsulation I like (I don't like the open at the beginning of your app and close at the end methodology). But if that "floats-your-boat" you can still use the low level VIs instead. I did look at savepoints. But for the usage cases I foresee in most implementations; there is no difference between that and Begin / End transactions. OK you can nest Begin / End but why would you? Its on the road-map. But I haven't decided when it will be implemented. If yo can think of a "common" usage case then I will bring it higher up the list. See my comments above. Indeed. And I would guess "Temp" tables are also in memory. I don't think there's much in it.