PDA

View Full Version : System File w/ 2nd record



Alan Felsted
5-Aug-2005, 01:35 PM
I provide very occasional support to a company running a 3.01b system (they
seldom need to call - it just works!) Last January they switched from a
Netware server to MS2000. A couple of months went by and one of their
system files showed up with a second record, thereby screwing up all of the
'last ??? number used' values.

I was able to fix it for them and all was ok until today when they called
with the same situation. My question - Could the switch to MS2000 server
cause this? If so, how can I prevent it?

Thanks!

Alan.

Martin
5-Aug-2005, 02:37 PM
We had this problem with an old system. The solution was simple; upgrade
to version 3.2 and run using dfruncon, don't forget to set the opLocks
registry setting on the server.

....MXP

Alan Felsted
5-Aug-2005, 09:12 PM
I doubt that will be an option. Is there any way of preventing it
programmatically?

"Martin" <martin@asckey.com> wrote in message
news:0BUnXUfmFHA.2188@dacmail.dataaccess.com...
> We had this problem with an old system. The solution was simple; upgrade
> to version 3.2 and run using dfruncon, don't forget to set the opLocks
> registry setting on the server.
>
> ...MXP

britk9
6-Aug-2005, 08:19 AM
Alan,

It sounds as though one (or more) of the machines is caching the record
buffer on "saves". Each version of Windows has it own quirky little way of
setting "deferred writes". Check each machine's O/S configuration for
"deferred writes" and set it OFF.

Even then, depending on the mix of O/S's you may not be able to stop this.
For example, a mix of Win95/98 with NT based machines is a recipe for
disaster. There was (is) even a technical bulletin from M$S about this on
the Access database some years ago.

Good luck,
Mike


"Alan Felsted" <fripco@yahoo.com> wrote in message
news:luDAnyimFHA.8072@dacmail.dataaccess.com...
> I doubt that will be an option. Is there any way of preventing it
> programmatically?
>
> "Martin" <martin@asckey.com> wrote in message
> news:0BUnXUfmFHA.2188@dacmail.dataaccess.com...
> > We had this problem with an old system. The solution was simple; upgrade
> > to version 3.2 and run using dfruncon, don't forget to set the opLocks
> > registry setting on the server.
> >
> > ...MXP
>
>

DavePorter
6-Aug-2005, 08:41 AM
Hi Alan,

Suggest you read this !
http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html

regards, Dave Porter


Alan Felsted wrote:
> I provide very occasional support to a company running a 3.01b system (they
> seldom need to call - it just works!) Last January they switched from a
> Netware server to MS2000. A couple of months went by and one of their
> system files showed up with a second record, thereby screwing up all of the
> 'last ??? number used' values.
>
> I was able to fix it for them and all was ok until today when they called
> with the same situation. My question - Could the switch to MS2000 server
> cause this? If so, how can I prevent it?
>
> Thanks!
>
> Alan.
>
>

DavePorter
6-Aug-2005, 08:45 AM
Hi Alan,

Forgot to mention - there is an easy way to deal with this too.
Check this out:
http://www.vdf-guidance.com/ContribPage.asp?Page=PKGGENREGCHECK&ContribRecId=85

But this does require VDF
( I don't think this will work with character mode !)

regards, Dave Porter


Dave Porter wrote:
>
> Hi Alan,
>
> Suggest you read this !
> http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html
>
> regards, Dave Porter
>
>
> Alan Felsted wrote:
>
>> I provide very occasional support to a company running a 3.01b system
>> (they
>> seldom need to call - it just works!) Last January they switched from a
>> Netware server to MS2000. A couple of months went by and one of their
>> system files showed up with a second record, thereby screwing up all
>> of the
>> 'last ??? number used' values.
>>
>> I was able to fix it for them and all was ok until today when they called
>> with the same situation. My question - Could the switch to MS2000 server
>> cause this? If so, how can I prevent it?
>>
>> Thanks!
>>
>> Alan.
>>
>>