[Netware 6 / Windows 2000 / Access97] Twijfelshare

[TXC]

Op mijn werk gebruiken we Netware 6 als netwerkbesturingssysteem. NU het volgende probleem:

Bepaalde gebruikers maken gebruik van een Access97 applicatie, terwijl we normaal Access2000 gebruiken. Om Access97 op deze specifieke PC's naast Access2000 te gebruiken heb ik een application object gebruikt om Access97 (dus niet heel office, maar alleen de standaardoffice bestanden + access97) te distribueren. Als ik nu een applicatie open met Access97 i.p.v. access2000 werkt dit goed.

Maar, nu heb ik de images van deze PC's geupdate en weer geghost naar de PC's met alle nieuwe win2k updates en de nieuwste netware client (4.90E SP1). Als ik nu (of via de nal of rechstreeks vanaf de share waar de applicatie op staat) de access97 applicatie start, werkt het meestal niet. De fout die Access97 geeft is dan: "Er is een schijf- of netwerkfout opgetreden". Maar het rare is, heel soms gaat het wel goed. Dus met de bestanden lijkt mij niets mis, en dus lijkt het mij aan het netwerk te liggen.

Maar deze fout is dus gekomen na de allernieuwste (had SP4 al, het zijn de updates van de afgelopen 2 maand ongeveer) updates van Windows 2000 en de nieuwste netware client die overigens overal in het netwerk goed werkt.

Ik heb al gegoogled, en vond daar alleen iets over het verzetten van de variabele temp en tmp naar een lokale map i.pv. de profielmap, maar dit holp helaas niet.
Iemand een idee?

[Jaymz]

Er staat me iets bij over Oppurtunisic Locking ism Office pakketen, maar hoe of wat weet ik niet meer

Wat gebeurd er overigens als je 4.9E SP1 erafgooit en de client eropzet die er opstond toen het werkte ?

[Koffie]

OpsLock zou je idd uit kunnen zetten, maar volgens mij uitten de meeste problemen zich in traagheid e.d bij OpsLock, en dergelijke melding snap ik niet helemaal icm OpsLock (maar de wonderen zijn de wereld niet uit ).

Probeer eens bij de Advanced options in de NW client "Filecaching" op disabled te zetten ?

[Arfman]

Aanvullend op Koffie: mocht dat helpen op die ene client kun je dmv het commando 'SET CLIENT FILE CACHING ENABLED=OFF' het voor de hele server + alle clients uitzetten. Wordt ook aangeraden door Novell als je NW5.1 of hoger gebruikt icm. W2K of WXP.

[Loesje]

OP-Locking geeft idd. problemen bij traagheid, maar ook specifieke problemen met Access en Excel. Ik denk dat uitzetten de oplossing is. (In de client bij filecaching)

[TXC]

Ik heb het net in de client uitgezet (bij de client properties). Helaas is dit niet de oplossing, het probleem blijft. Misschien moet ik het op server niveau uitzetten op de console. Het lijkt mij dat als de andere computers nog wel oportunistic locking gebruiken dat het niet helpt om het op client niveau uit te zetten.

Het probleen ligt hier waarschijnlijk wel ergens, want ik ben er net achter dat als ik niemand anders tegelijk van dat database bestand gebruik laat maken, dat het dan gewoon werkt.

Koffie schreef op 25 februari 2004 @ 15:48:
[...]

Als je de client setting wijzigt moet je wel de client PC rebooten voordat het werkt he

Bedankt dat je me erop wijst, maar de client meldt dat zelf ook al als je de instelling wijzigt

[ Voor 24% gewijzigd door TXC op 25-02-2004 16:13 ]

[paulhekje]

checken de rechten op de directory eens, als je alleen rechten op de access mdb-file hebt wordt deze single user...

[TXC]

paulhekje schreef op 25 februari 2004 @ 15:24:
checken de rechten op de directory eens, als je alleen rechten op de access mdb-file hebt wordt deze single user...

Nee de andere gebruikers hebben er geen last van en kunnen de database gewoon samen gebruiken, alleen op een computer waar ik de nieuwste client op heb gezet en de laatste windows 2000 updates werkt het niet.

[Koffie]

Ik heb het net in de client uitgezet (bij de client properties). Helaas is dit niet de oplossing, het probleem blijft

Als je de client setting wijzigt moet je wel de client PC rebooten voordat het werkt he

[TXC]

OK, ik heb nu ook client file caching op de server uitgezet. Daarna heb ik een paar werkstations gereboot, en vervolgens de database laten openen. Vervolgens heb ik op de pc waar bij het openen de fout komt getest of het nu wel werkt, maar helaas. Client file caching lijkt niet de veroorzaker te zijn.

Waar ik dus wel achter ben is dat de problemen zich alleen voordoen als 1 of meerdere mensen de database al open hebben. Is de gebruiker op de computer waar het vaak niet op werkt de enige gebruiker van de database, dan werkt het weer wel.

[ Voor 1% gewijzigd door TXC op 25-02-2004 16:27 . Reden: typo ]

[Falcon]

Het ziet er na uit dat het probleem zich ook bij deze gebruiker bevind -> [rml][ ACCESS 97] fout nieuwe database[/rml]

[Jaymz]

Als je op die bestanden het 'Transactional' vlaggetje zet ?

[f@stmem]

Ik heb dit ook gehad na installatie van SP4 voor NW6.
Je moet de oplocks op de server uitzetten door het volgende commando:
set Level 2 OpLocks Enabled = off

Hierna wel de server herstarten.

[ Voor 11% gewijzigd door f@stmem op 25-02-2004 17:00 ]

[TXC]

Ik zal het vrijdag even proberen, heb morgen vrij

Ik heb geen nieuwe service pakcs aan de server toegevoegd, maar alleen de client (workstation) software geupdate zoals ik al zei.

Bedankt voor de huidige reacties in ieder geval.

[Verwijderd]

@paulhekje: inderdaad ...

Ik heb net hetzelfde probleem gehad bij de migratie naar XP (met office 2000).

Blijkt dat je inderdaad alle rechten moet hebben in de directory waar de mdb staat, niet enkel append, maar ook delete-rechten, anders blijft de .lck file staan van access 97. Access 2000 heeft hier geen last van.

Check es na of iedereen voldoende rechten heeft op die directory (?)

[TXC]

Verwijderd schreef op 25 februari 2004 @ 19:24:
@paulhekje: inderdaad ...

Ik heb net hetzelfde probleem gehad bij de migratie naar XP (met office 2000).

Blijkt dat je inderdaad alle rechten moet hebben in de directory waar de mdb staat, niet enkel append, maar ook delete-rechten, anders blijft de .lck file staan van access 97. Access 2000 heeft hier geen last van.

Check es na of iedereen voldoende rechten heeft op die directory (?)

heb net even gekeken, de gebruikers hebben op access control na alle rechten. Dus read, write, create, modify en filescan.

Nog iets anders:

fastmem schreef op 25 februari 2004 @ 16:58:
Ik heb dit ook gehad na installatie van SP4 voor NW6.
Je moet de oplocks op de server uitzetten door het volgende commando:
set Level 2 OpLocks Enabled = off

Hierna wel de server herstarten.

Weet iemand wat het verschil is tussen level 2 opslock en gewoon opslock?

[TXC]

Ik ben er eindelijk achter wat het probleem is:

er zit een fout in netware client 4.90ESp1. Ik las net even de changelog van de nieuwste client door (4.90E SP1a) en daar staat het volgende:

A change made in the 4.9 SP1 version of NWFS.SYS is the cause of this problem. When Workstation1 opens an Excel file that resides on a server, the client can request a lock on the file. The error occurs when Workstation2 requests to open the same file while Workstation1 still has it open. If the Novell Client was behaving correctly, the Workstation2 user would not get the "[FILENAME] cannot be accessed" error, but get a "File in Use" message that says: "[FILENAME] is locked for editing by '[USER]'." The message dialogue box would also give the Workstation2 user the option to open the file as "Read Only".

While this TID refers to Excel files, the same has been seen with Access Databases. Other applications can also be affected.

Dit artikel is hier te bekijken

[ Voor 5% gewijzigd door TXC op 19-04-2004 12:43 . Reden: Link met [URL=""][/URL] ]