Desktop VCL application that is based on SQLite (with Zeos lib). Now I need to expand it allowing some Windows LAN clients of the same application to connect to SQLIte database for some (limited) functionalities.
Desktop VCL application that is based on SQLite (with Zeos lib). Now I need to expand it allowing some Windows LAN clients of the same application to connect to SQLIte database for some (limited) functionalities.
Just to see what I'm able to do, I was trying to connect clients installations to main installation (call it server) with tethering (I use Berlin) , using shared resources (DATA) to exchange some small datasets (using XML). But I'm experiencing problems mainly with tethering: despite my efforts at this point I'm still not able to identify the client that asks the server for a query (AResource.Hint that looses his content on his way to the client, and AResource.Profile.Identifier that, too, reaches my clients completely blank).
So, starting from SQLite as database,do I have a chance to engineer the new (very light) C/S version without a complete rewrite of the database part (and a new database technology)?
Thanks for your help!
Just to see what I'm able to do, I was trying to connect clients installations to main installation (call it server) with tethering (I use Berlin) , using shared resources (DATA) to exchange some small datasets (using XML). But I'm experiencing problems mainly with tethering: despite my efforts at this point I'm still not able to identify the client that asks the server for a query (AResource.Hint that looses his content on his way to the client, and AResource.Profile.Identifier that, too, reaches my clients completely blank).
So, starting from SQLite as database,do I have a chance to engineer the new (very light) C/S version without a complete rewrite of the database part (and a new database technology)?
Thanks for your help!
Stop, SQLite is not meant to be used that way. If you need network clients to check data, then go with a real database server, not an embedded one. You are going to open a door to hell.
ReplyDeleteHeinz Toskano Yes Heinz, I know that SQLite is an embedded db, and his limits. I was wondering how far the creativity ;) of Delphi developers could go, using tethering for a very light "companion apps" use as clients (http://docwiki.embarcadero.com/CodeExamples/Berlin/en/RTL.BDShoppingList_Sample sample explores something in that direction)
ReplyDeleteWhy not try to find the right tool for the job?
ReplyDeleteDavid Heffernan Thanks, David. In this situation, a Windows desktop application that need to let "light" clients to read and, sometimes, to write on his DB, do you recommend to throw SQLite out of the window and substitute it with..?
ReplyDeleteYou can use cubeSQL or switch to Firebird etc.
ReplyDeletehttp://www.sqlabs.com/cubesql.php
Markus Kinzler Thank you Markus, as said I know that I could switch to a classic (not embedded) solution. More precisely I was looking for a solution different that the rewrite of the whole database code in a C/S logic , and with a new DB engine.
ReplyDeleteWith Firebird you can easy switch between embedded use and Server without change of code (just adapt connection string). Even the same database file can used.
ReplyDeleteMarco Cirinei if there were such a solution don't you think it would be sold to the masses by now?
ReplyDeleteJeroen Wiert Pluimers Okay, my attempt to find a light alternative to a C/S approach was a crystal clear failure. Maybe Firebird could be my first choice now
ReplyDeleteMarco Cirinei you will run through a lot of issues. Select another database engine, something like postgresql (yeah, i'm a big fan). You should also considere using a multitier layer (datasnap, tms xdata, mormot to name a few of them)
ReplyDeleteMarco Cirinei I'd recommend not going with Firebird and taking Stéphane Wierzbicki 's recommendation of PostgreSQL. Firebird 3.0 was more than 10 years late and it's still woefully behind modern databases (such as PostgreSQL). There are very few developers coding it and a very small user base (mostly centered in former Soviet states in Eastern Europe). PostgreSQL has much wider popularity, better support, yearly releases, five years of support for older versions, etc.
ReplyDeletehttp://www.sql-workbench.net/dbms_comparison.html
Quite a long time ago now we used (IIRC) NexusDB components to turn what was normally a single local desktop application into an occassional hybrid, so a couple of other PC's running the same app could sensibly access and update the same data. One machine would then be the designated "server" and the others would be clients. Nexus made this relatively easy and transparent. Thought I'd mention it.
ReplyDeleteThanks all for your help. Sven Harazim I had already implemented a safe (a threaded queue) write access to SQLLite so the temptation ;-) is to spend one or two days more in this, and after that go straight with PostgreSQL or A. Bouchez very interesting links (SynDBRemote)
ReplyDeleteI'd also recommend PostgreSQL in general. It's powerful, mature, and entirely Free.
ReplyDeleteI'm choosing it where in the past I would've chosen mssql or oracle for complex projects (if the budget allowed) and MySQL for simple ones.