Uforklarligt datatab i C5.

Lyder meget sandsynligt, at det har noget at gøre med måden de tilgås på.

Hvis en database skal tilgås af mere end 1 bruger, så bør man tænke client-server løsning med det samme. For små antal brugere *kan* man godt lave løsnigner, men jeg har ingen idéer om C5 giver problemer eller ej.

Et muligt "dataflow" for dit problem kunne se således ud:

Bruger 1 læser (fra) tabellen.

Bruger 2 læser (fra) tabellen.
Bruger 2 bogfører til tabellen.
Bruger 2 udskriver og kontrollerer

Bruger 1 (over)skriver tabellen
Bruger 1 ser at rettelserne er OK.

Bruger 2 mangler sine tilføjelser, da de er overskrevet af bruger 1.

Kan hun have fat i en forkert database? Forstået på den måde at hendes genvej er forkert på en maskine men ikke på andre? Eller at hun har en lokal kopi af C5 liggende, som genvejen så peger på?

Lyder underligt. Jeg kan sige at vi sidder et sted mellem 7-12 brugere og tilgår de samme databaser uden problemer, vi har endnu ikke oplevet/opdaget datatab. Vi sidder dog på samme lokation, men hvis du siger at den ene bruger logger på via Terminal Services eller lign. skulle der ikke være problemer.

Der er problemer (i flg Navisions Partnerguide) med TS. Navision garanteres ikke under TS pt.
Problemet er primaert i at der tilgaaes via en terminalserver, men at C5 ligger paa en anden server. Flyttes C5 over paa selve Terminal serveren, er der normalt ikke noget problem.

Navisions dokument:

Many of the errors reported by users and partners with regards to the running
of Navision XAL on the Windows 2000 Terminal Server have caused a great
deal of frustration in the Partner Channel.
This paper defines the current status of the ongoing test and error diagnosing
performed on Windows 2000 Terminal Server.
The Microsoft Q272582 hotfix (containing the files RDBSS.SYS in version:
5.0.2195.3642 and MRXSMB.SYS in version: 5.0.2195.3642 ) contains the
four fixes listed below:
1. Q289509: Windows 2000 redirector may leak file handles
2. Q285803: NetBIOS sessions may be dropped in Windows 2000
3. Q284247: Invalid file handle error messages when remote files are used
and a sharing violation occurs.
4. Q272127: "STATUS_UNEXPECTED_NETWORK_ERROR" error
message from redirector to Terminal Services client cessions
Unfortunately one problem still exists:
1. Q294816: Programs run from network share on a terminal server close
or generate errors.
This means when programs are loaded from a remote network share (not from
the Windows 2000 Terminal Server itself), problems similar to the one
reported, may occur.
To verify whether moving just the binaries (.EXE, .DLL etc.) to the Windows
2000 Terminal Server, which would be a manageable workaround, the
Navision Danish Support and Microsoft Technicians have visited selected
Navision XAL 3.10 applications on various Windows 2000 Terminal Server
sites to test the mentioned workarounds.
The current status however, is that this is insufficient to ensure a stable
environment. In fact all Navision XAL application files and the Native database
have to be moved to the Windows 2000 Terminal Server.
For stability reasons, Microsoft cannot provide a Windows 2000 fix for this
problem. The problem will be fixed in the .NET Server (Windows XP family).
The problem is not present in Windows NT4 Terminal Server.
To sum it all up, if you require a stable Terminal Server environment here and
now your options are:
• For smaller sites, move all of the Navision XAL files, including the Native
databases, to the Windows 2000 Terminal Server.
• For large installations requiring multiple Terminal Servers, use Windows
NT4 Terminal Servers.

Det skal siges, at der selvfoelgelige ogsaa kan vaere tale om programmeringsfejl, men er det i std. C5 burde det ikke vaere tilfaeldet!

til jpvj: Jeg forstår hvad du mener, men i dette tilfælde er der kun en bruger der bogfører i det pågældende regnskab. Kunden har mange regnskaber og de de øvrige brugere bogfører i andre regnskaber. Der er desuden også tale om client/server løsning. Remote connection er terminalserver løsning.

til mariaf: Jeg tænkte ligesom dig til at begynde med, om der kunne være noget på genvejen så det har jeg undersøgt.

Til dma: Ifølge Microsoft skulle dette problem være løst i Window 2003 Server og selv om det var samme problem, så skulle det give fejlmeddelelser og aldrig datatab, så jeg tror desværre heller ikke dette kan forklare fænomenet, men mange tak for forsøget.

Til dma: Vi har haft præcist de beskrevne problemer over TS og Citrix. Dette giver ikke anledning til datatab og er derfor ikke problemet i nævnte tilfælde.

Mon ikke i skal prøve at rette i c5.ini. Der står som default -p-. Prøv at rette til -p5. Dette giver en større sikkerhed i flerbrugerløsninger (på bekostning af hastigheden).

Check i øvrigt under generelt-kartotek-datastatus under kollonnen TT. Den skal helst være tom og indikerer netværksproblemer hvis der står store tal. Prøv funktionerne under generelt-tilpasning-vedligeholdelse (tag backup først)

Endelig kan der jo være tale om en dårlig disk eller et forstyrret backup-program som kopierede data frem og tilbage(det har jeg faktisk været ude for). Der plejer at være en fornuftig forklaring.

Det lyder på mig som om at der er lavet nogen tilretninger i dette system af en som ikke har sørget for at balancere antallet TTSBEGIN og TTSCOMMIT. Det lyder som om at der mangler en TTSCOMMIT et sted. Hvis det er tilfældet kører hele dagens arbejde i een transaktion i databasen, som bliver abort'et når programmet lukkes ved fyraften. Der burde bare komme en advarsel om "at programmet er ved at lukke ned, men der er stadig åbne transaktioner på kartoteket xxxxxxx". Jeg kan dog ikke huske ordlyden nøjagtigt. Og da der kun arbejder een bruger i systemet opdages det ikke at det er låst.

Til mcregn:
-p- og -p5 har intet med hinanden at gøre. -p- sørger for at der først committes til filsystemet når transaktionen committes. Denne parameter blev slået fra som default ved et uheld i kernen fra XAL 2.71.1/C5 1.70 og kan aktiveres uden risiko for datatab. -p5 sørger for at klientens buffer til databasen bliver flushed hvert 5. sekund.

Kolonnen TT kan heller ikke bruges som en indikator på netværksproblemer. Det er jo bare antallet af abortede transaktioner og disse kan lige så godt opstå i databasen af alle mulige andre grunde.

-Broholm

Til Broholm: Du ramte fuldstændigt rigtigt. Der er en mindre tilretning med lige netop dette problem så vi føler os ret overbevist om at en rettelse af dette er løsningen. Vi takker mange gange.