Am 25.12.2012 22:18, schrieb Çağlar Orhan:
But every client has MS *.hta files and connecting to sqlite over ODBC driver with vbscript.
What you rely on in this case, has nothing to do with the WebServer (IIS) ... meaning the WebServer is not used as a decoupling layer (over http). What you do instead is FileLevel-Access over a (Network-) Share (SMB/CIFS). In this mode, the client-machines are opening the DB separately - and the DBFiles Pages are transferred to *each* client independently: [.hta->vbscript->ADO(ODBC)->]...network...[<-SMB/CIFS]
That means 5-10 or few larger client counts make connections to that unique sqlite file on the IIS server.
As said, these connections have nothing to do with the IIS (as a Service on your ServerHost). Your ServerHost-*Machine* was simply set up, to provide (beside the IIS) also the SMB/CIFS-Service, to be able to act as a (Network-)FileServer (which then interacts with your clientside ADO/ODBC-Driver at the Network-FileLevel). In this mode, SQLite-concurrency is handled over (NetworkLayer-) FileLocks - and these FileLocks do make problems sometimes. The more stable mode would be, to use your IIS as a real decoupling layer, and access the DB-Files at the server-end *locally* (e.g. behind an *.asp-File, which can hold VBScript too - but delivers disconnected Rs to your Clients, after retrieving them over a local DB-Connection against a Server-local SQLite-File): [.hta->vbscript->XMLhttp-Obj]...network...[<-IIS<-.asp<-ADO(disc. Rs)] Your current (CIFS-)access-mode would also work, when you completely disable the IIS-WebService on your Server-Machine - and open your ADO(ODBC)-connections directly within VBScript (without any .hta). If you have very stable Network-Connections (no WLAN involved, very stable ClientMachines (no Notebooks, which may power down "on an open connection" due to longer inactivity), then the SMB/CIFS- Mode can work relatively reliable, especially when you really only have 5-15 clients "to serve" in that mode. But in case there's more clients - or when you have a certain potential for "client-machines, disconnecting unexpectedly" - then it's better to work over IIS/.asp instead of CIFS, to do "server-local" DBFile-Access over http. But also that "Server-local-mode" could cause certain concurrency- problems (but then more performance-related ones) ...not as many as when working with Network-Filelocks as the only possible "concurrency-signalling-mechanism" available to SQLite. Olaf _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
