Hello,
>> My understanding, after all of your helpful comments, currently is: >> >> Simultaneous reading of a server file by different clients is safe, as >> long as the file doesnt get changed at all (at least in a time scale >> where the Client Os could cache it). Mrs.> Remove your parenthesized exception and this is correct. My current plan is: Store the (readonly) database on the server and include version info in a table in the database. Each time the client app starts, it accesses the server database and checks the version info. Based on this it decides whether it needs to copy the database file locally (the server version is newer or there is no local version) or can use the current local version (the version of the server database is the same as the local version). Its possible that more than one client will be accessing this version info simulataneously. Can there be any problem? Using sqlite to read this version info via a SELECT should map cleanly to a read only access to the disk file, right? This is the only point where imnot fully sure. According to the above should then be fine? The server database will need to be updated at some stage. The sys admin will haye to be responsible for seeing that no client is accessing the file while its being updated (by disconecting the server from the network or doing the job at niight when all clients are off, or just making sure that none are running my app or whtever). What should I advise him is a necessary/reasonable procedure, and what are the worst case scenarios for each appraoch? As far as I can understand, the only thing that absolutely must be ensured is that no app starts after the sys admin begins replacing the file, and before he's finished, because then the client would possibly get corrupt data. This could be ensured eg by temporarily disconnecting the server from the network. Given this worst that could happen (which is extremely unlikely, but not completely impossible), due to client os caching, would be that upon restarting the clients then dont know that the serever database is newer, and dont copy it locally it, and instead continue to work with the old data (local version). Does this sound like a good approach? >> The same applies to sqlite accesses since it just uses regular files. >> And when you only querying the database (not changing the data), you >> are just reading the database file .. ie sqlite doesnt do anything >> which would break the clients only reading condition. >> >> Am I right so far? Mrs.> Almost. Mrs.> You make a distinction between Client and Server and I don't Mrs.> think you know who they are. Whats that supposed to mean? Mrs.> It's helpful to understand that the server cannot update files. Ever. Mrs.> Only clients can update files. The server coordinates these updates. In Mrs.> reality, in many cases, the server coordinates fine. In others, it fails Mrs.> miserably. You can work with the server just as a normal machine. It happens to be functioning as a network server for clients on the network. Eg. the system admin can copy a database file from a cd onto the harddisk of the server. The server updates the database here, not the client. >> The size of a file depends for example on the cluster size of the >> underlying partition. And regardless is of little value in comparing >> two files; the same file size/name doesnt mean two files are >> identical. Mrs.> The size of a file does not depend on the cluster size of the underlying Mrs.> partition. That's how much SPACE the file takes up. Mrs.> Whether or not your filesystem records the size of a file isn't Mrs.> important. It is. Its all that matters here. Mrs.> The concept of file size exists, and it has nothing to do Mrs.> with clusters or blocks or extents... almost all Mrs.> filesystems...correct One wants to reliably determine this invariant size and not the space occupied on disk or some other measure reported which depends on cluster size or whatever. "Almost" or "roughhly" is not reliable. Mrs.> The test is not to determine whether or not the files are identical, It is. Mrs.> but if one has been changed. This method will certainly download Mrs.> files when they haven't been changed (although it's unlikely). Mrs.> This unusual case wastes some bandwidth. In contrast to Mrs.> downloading it all the time, where you always waste bandwidth. If you cant tell when files are identical, you cant tell when you dont need to download, so you need to download always, so you needent bother checking the filesize in the first place. Mrs.> If you're looking for cross-platform you need to select protocols that Mrs.> have well defined semantics. HTTP sounds like a good bet. Full file copy Mrs.> sounds like a better one. My app will access the files on the network (LAN) as if theyre local. -- Best regards, djm mailto:[EMAIL PROTECTED]