Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread C/S and Corruption
Tue, Aug 8 2006 8:26 PMPermanent 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 AMPermanent 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 Smile

Ralf
Thu, Aug 10 2006 11:01 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 AMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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

Image