Clay Dowling wrote:
Alex Chudnovsky said:I think wrapper is fine (apart from me having to write my own wrapper on top of to ensure database
I am using ADO .NET wrapper
(http://sourceforge.net/projects/adodotnetsqlite/) and I am not sure
if I can just "drop in" new .DLL -- the wrapper was not updated for a
while now :(
I feel moderately bad about that, because I have recommended that particular wrapper in the past. To be honest, I'm not a giant fan of ADO.NET. It seems to have taken us away from the database-independent that we got with ADO and given us a differnt object to use for each different database we connect to.
Is there a possible alternative for you to ADO.NET?
Clay
won't get locked, sometimes it still does and reconnection does not held :( , but thats another story).
What appears to have happened (somehow) is this -- header of the database file had some binary junk
written in it, thank God everything else was untouched and I was blessed with this crazy idea to use
hex editor and copy header from backup (fairly outdated, which is my fault, now I have proper snapshots
taken every 10 minutes). So, I can't see how ADO.NET wrapper could have gone as low as writing
new (incorrect) header of the database. The reason I posted all this is (not to knock great product
such as SQLite), but just to show way to recover database from corruption in this sort of cases.
Hex editing might not be sexy, but it was a solution in my case, and I feel very good about trying it
rather than giving up and trying to recover data from database file itself :)
Sadly my solution is to move to PosgtreSQL for server software since I was running into concurrency
issues anyway. Client software will continue to use SQLite since its low concurrency environment and
clients seems to be working okay.
regards,
Alex
