Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 8 of 8 total |
C/S and Corruption |
Tue, Aug 8 2006 8:26 PM | Permanent Link |
"Al VAs" | Hi,
Just a question. Taking the potential of application or database engine programmatical issues away, is it safe to assume that under a client/server setup, you would expect more stability than in a non client/server setup. I always understood that in a non-client situation that if a PC was shutdown at the wrong moment, then writes could be unfinished, whereas in a client/server it is the server process that does the writing and therefore a client shutdown would be of no consequence (once the SQL statement has been delivered to the server). Just after clarification, I was never very studious at school Alex |
Wed, Aug 9 2006 6:03 AM | Permanent Link |
"Jose Eduardo Helminsky" | Al Vas
In a C/S setup, every updates occurs at server side and therefore any client crashes does not matter to the data. If the client process is inside a transaction, server "detects" client down and apply an internal rollback. But of course if server crash the the possibility of corruption exists. This is true for *EVERY* database engine in the market. I have been using C/S since the first version and I´ve never need to repair tables. Eduardo |
Wed, Aug 9 2006 2:15 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alex,
<< Just a question. Taking the potential of application or database engine programmatical issues away, is it safe to assume that under a client/server setup, you would expect more stability than in a non client/server setup. >> Yes. << I always understood that in a non-client situation that if a PC was shutdown at the wrong moment, then writes could be unfinished, whereas in a client/server it is the server process that does the writing and therefore a client shutdown would be of no consequence (once the SQL statement has been delivered to the server). >> Correct. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Aug 10 2006 4:43 AM | Permanent Link |
"Al Vas" | Hi Tim,
Would it be safe to assume then that since most of our clients are using client/server for this application, that these index corruption issues we are experiencing are happening in the database engine server? How does making Flushbuffer calls from clients work in this scenaro? Thanks Alex "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:F9B30A0F-9226-409E-B55F-9DB294940FA6@news.elevatesoft.com... > Alex, > > << Just a question. Taking the potential of application or database > engine programmatical issues away, is it safe to assume that under a > client/server setup, you would expect more stability than in a non > client/server setup. >> > > Yes. > > << I always understood that in a non-client situation that if a PC was > shutdown at the wrong moment, then writes could be unfinished, whereas in > a client/server it is the server process that does the writing and > therefore a client shutdown would be of no consequence (once the SQL > statement has been delivered to the server). >> > > Correct. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > |
Thu, Aug 10 2006 5:46 AM | Permanent Link |
"Ralf Mimoun" | Al Vas wrote:
> Hi Tim, > > Would it be safe to assume then that since most of our clients are > using client/server for this application, that these index corruption > issues we are experiencing are happening in the database engine > server? I'm not Tim, but I'd vote with Yes. > How does making Flushbuffer calls from clients work in this > scenaro? It tells the server to flush the buffers. Or at least that's what the name of the message sent from the client suggest. Wait for Tims answer to take my word Ralf |
Thu, Aug 10 2006 11:01 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alex,
<< Would it be safe to assume then that since most of our clients are using client/server for this application, that these index corruption issues we are experiencing are happening in the database engine server? >> Yes, that has always been without doubt. Nothing external to DBISAM short of an improper shutdown or someone editing the tables with a hex editor will cause corruption. << How does making Flushbuffer calls from clients work in this scenaro? >> The same as with non-C/S. However, they also have no bearing on this issue. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Aug 11 2006 3:33 AM | Permanent Link |
Jaweed Saleem | Tim Young [Elevate Software] wrote:
> Alex, > > << Would it be safe to assume then that since most of our clients are using > client/server for this application, that these index corruption issues we > are experiencing are happening in the database engine server? >> > > Yes, that has always been without doubt. Nothing external to DBISAM short > of an improper shutdown or someone editing the tables with a hex editor will > cause corruption. > > << How does making Flushbuffer calls from clients work in this scenaro? >> > > The same as with non-C/S. However, they also have no bearing on this issue. > Hi All, Just need to clarify something. 1. 4 clients running on C/S. 2. They're all working on the same table. The session has pessimistic locking. They're putting in a combined 300 entries per day. 3. A couple of the clients experience very slow operations (let's say due to programming issues) while in the process of editing records. They think the program has frozen and decide to control + alt + delete out of it. My question is that because it's pessimistic locking, those records that the frozen clients are working on has been locked from the point of Edit. Even though the server engine is processing requests, would the "crashing out" cause any mismatch between indexes and table data? I would imagine that this would be the same as if clients had locks on records and the server crashed? Or does the server engine have the smarts to be able to deal with situations like this? Pardon my ignorance at the way the C/S server engine processes requests. Jaweed |
Fri, Aug 11 2006 12:03 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Jaweed,
<< My question is that because it's pessimistic locking, those records that the frozen clients are working on has been locked from the point of Edit. >> Yes, but they will also be removed when the session is removed according to the dead session settings on the database server. << Even though the server engine is processing requests, would the "crashing out" cause any mismatch between indexes and table data? >> No, not at all. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Friday, March 29, 2024 at 03:30 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |