In a Client Server setup and with the EDB database hosted on a dedicated Windows Server would it be possible for  a workstation program to cause database corruption either for a single threaded app or multi threaded app

And with this setup is it necessary or advisable to implement the flushbuffers command  For instance I include a Table.flushbuffers line in the AferPost and AfterDelete events of all my Tables  This was what I used to do for my older DBISAM file/server apps Can I now remove them

Thanks

Michael

>In a Client Server setup and with the EDB database hosted on a dedicated Windows Server would it be possible for a workstation program to cause database corruption either for a single threaded app or multi threaded app

It would be interesting to know if this is something that's happened or a theoretical question. I'm going to assume the latter.

SINGLE THREADED:
It is possible but very unlikely. Any program writing data to disk can cause corruption. In that sense, unless you mix f/s and c/s it will have to be the server that would cause corruption. Since the server (and ElevateDB) are well written and well behaved its improbable that it will cause corruption. If it does happen it could be down to a h/w fault (eg faulty network card) or interference from some other piece of software (eg a/v grabbing onto a file when it shouldn't - unlikely but the only one I can come up with off the top of my head).

MULTI THREADED:
This is much more likely to cause corruption UNLESS you follow the rules on isolation. If you do the probability drops way down and we end up back in the h/w or other s/w interfering causing corruption.

If you're actually experiencing corruption then in the immortal words of C5 "need input"

>And with this setup is it necessary or advisable to implement the flushbuffers command For instance I include a Table.flushbuffers line in the AferPost and AfterDelete events of all my Tables This was what I used to do for my older DBISAM file/server apps Can I now remove them

You shouldn't need flushbuffers

Roy Lambert

Michael

I've been using EDB in fairly challenging situations (businesses in Africa with poor power-supplies and hardware) for about 10 years. I have had a couple of instances of corruptions over the whole of that time. Usually brought about by a combination of poor hardware + power failures. Given the circumstances I work in I think this is amazing.

I have worked on projects alongside big data businesses (SAP / SAGE) and had to bail them out over and over again as their data got corrupted due to the poor infrastructure, but EDB sailed on happily.

I don't use Flushbuffers, but I don't work with tables (Delphi TTable) either. I call data with a Query and then post the Update with a SQL Update statement, so the only live connection I have into the database at any point is to 1 record, and EDB can cope with network failures around this really well, i.e. if I call a record, then unplug the LAN cable, I can edit the record in my app while disconnected then reconnect the LAN and post everything works, if I try to post with the LAN disconnected EDB says "can't find the DB", but there is no issue with corruption, just a hanging session locking 1 record which times out after a few minutes.

I use multi-threaded apps a little, and as Roy says it is not much of an issue. You have to create separate TDatabase/TSession/TQuery connections for each one, and ensure they are not posting to the same records simultaneously, I have plenty of users connected to a database each on their own session anyway, so you have to think of this even in a single threaded context.

I hope this is useful

Adam

Michael Saunders wrote:

> In a Client Server setup and with the EDB database hosted on a dedicated Windows Server would it be possible for  a workstation program to cause database corruption either for a single threaded app or multi threaded app

I'm going to add to the others, I hope, by saying a simple "No", if what you are saying is literally right. That is, you are using it as client to server and not client to files on a server.

The server will protect the database against corruption due to disconnections etc. Data may be wrong depending on your transactions etc, but won't be corrupt.

--

Matthew Jones

Michael,

<< In a Client Server setup and with the EDB database hosted on a dedicated Windows Server would it be possible for  a workstation program to cause database corruption either for a single threaded app or multi threaded app >>

You've already received very good responses, so I don't have much to add.  However, just to give you the official response: no, it would not be possible.  The only way you can see corruption when using the ElevateDB Server is if the server process and/or server machine go down unexpectedly while the database is being updated.  However, even then there are excellent table verification facilities in ElevateDB to verify that the tables are okay prior to restarting the ElevateDB Server, and they operate very quickly.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks for all replies  

I asked the question really so as to satisfy a nervous client  

MIke

On 3/22/2017 6:19 PM, Michael Saunders wrote:
> I asked the question really so as to satisfy a nervous client

Then i would get a UPS also to reduce risk even further.

Raul

Raul

>Then i would get a UPS also to reduce risk even further.

I used to believe in that approach, and still do where you can afford the correct type of UPS. If you can't my approach is to use a laptop as the server - add in some spike protection and you have a pretty solid system.

Didn't used to be possible but these days you can stuff enough disk & RAM in.

Roy

Roy Lambert wrote:

> where you can afford the correct type of UPS

They aren't that expensive! All of our kit has a UPS. Well, anything at all important.

--

Matthew Jones

Matthew


>They aren't that expensive! All of our kit has a UPS. Well, anything at all important.

At one point I bought micro UPSs for each piece of kit - PC or router. They gave me somewhere around 15 - 20 minutes in the event of a power cut which generally meant that I could shut stuff down gracefully. I still have them (with new batteries) for desktops and routers

Roy