Peter,

<< There are very few situations in my app that could benefit from separate
threads as it uses modal dialogs almost everywhere. However I can see one or
two spots that might benefit from being able to pass the process off to a
thread while allowing the user to get on with another, hence the interest.
>>

Okay, that is a good candidate, especially if the processing is taking place
in the client application.  If you want to email me with an example of the
code that you'd like to put into the thread, I can give you a more specific
example of how it would be done.

--
Tim Young
Elevate Software
www.elevatesoft.com

<<Sessions u need eyes in your bum with them >

I posted a reply to this message, but it hasn't appeared. I'll try to recall what I put in
the original.

I have run my app for >5 years with AutoSessionName set to False, and it has been notably
stable. Relatively recently about 12 sites have experienced a weird form of data
corruption, in that when they edit (or insert) a Client record, the last ~290 records all
get the same data. There is no error message that I am aware of when this event takes place.

The Client table is corrupt - the RecordCount displayed in DBSys is different from the
number of rows, until the table is repaired. Then the record count is Ok, but everyone in
the last couple of hundred records shares the same name, and other details.

Could there be a connection between this corruption and the AutoSessionName property?

Regards

Peter

Peter

>Could there be a connection between this corruption and the AutoSessionName property?

No. If it was only one site I'd suggest hardware. With a dozen I'd think program error. Unless its c/s over a WAN and all 12 sites are linking to the same central site in which case again I'd suggest hardware.

Roy Lambert [Team Elevate]

"Peter" <peter@petercrain.com> wrote in message
news:4F9EAE0F-8292-450C-9085-8EC3D6493757@news.elevatesoft.com...
>
> I have run my app for >5 years with AutoSessionName set to False, and it
> has been notably
> stable. Relatively recently about 12 sites have experienced a weird form
> of data
> corruption, in that when they edit (or insert) a Client record, the last
> ~290 records all
> get the same data. There is no error message that I am aware of when this
> event takes place.
>

Ok 5 years no problems, then 12 sites have weird data corruption. The data
corruption
without errors is a classic session issue. I doubt it in your case I bet
them 12 sites have
upgraded the OS and introduced an as yet unresolved MS issue. Ask them for
the last
OS update date.

> The Client table is corrupt - the RecordCount displayed in DBSys is
> different from the
> number of rows, until the table is repaired. Then the record count is Ok,
> but everyone in
> the last couple of hundred records shares the same name, and other
> details.
>

Wow I hope its not my gas bill your app is working on. Sounds like that last
record was
left hanging about so everyone else picked it up. Sessions are well known
for weird they
screw everything up even the math. I think your app worked ok for 5 years
cos it was
correct at the time but either the OS has changed or maybe some piece of
office hardware.
Has anyone installed a new fangled router or some other item.
When you say 12 sites are they on the same lan or 12 different locations ?

> Could there be a connection between this corruption and the
> AutoSessionName property?
>
Sorry Peter I cant answer that only you can track it down, ask them was
their OS updated
did they change any hardware and backtrack. As it worked without error for 5
years then
I guess the corruption was introduced by one or other of my suggestions.
Get on the phone ask about updates or go and see for yourself as you never
get the whole
truth from clients.
Sorry Peter its a bummer.
Rita

Peter,

<< I have run my app for >5 years with AutoSessionName set to False, and it
has been notably stable. Relatively recently about 12 sites have experienced
a weird form of data corruption, in that when they edit (or insert) a Client
record, the last ~290 records all get the same data. There is no error
message that I am aware of when this event takes place. >>

Are you using multiple threads in conjunction with AutoSessionName=True ?
If not, then AutoSessionName has nothing to do with such a problem.  The
session name is mainly irrelevant in single-threaded applications.

--
Tim Young
Elevate Software
www.elevatesoft.com

<<Are you using multiple threads in conjunction with AutoSessionName=True ? >>

No, single thread, & AutoSessionName was always False.

The sites are not connected with one another; not sure what OS they use so I'll try to
find out.

Regards

Peter

Peter,

<< The sites are not connected with one another; not sure what OS they use
so I'll try to find out. >>

I would suspect the issue is most likely, in this order:

1) A bug in DBISAM 3.x, possibly with something like CopyOnAppend.

2) An issue in the application that causes multiple posts of the same data,
but this would be hard to do if there is a non-autoinc primary key defined
for the table.

--
Tim Young
Elevate Software
www.elevatesoft.com