9-5-7 Codepages aangebracht, nog steeds fouten in leestekens

[pascal]

We komen erachter dat na het overzetten van de update (Test > Produktie) de leestekens verkeerd staan (zie hieronder).
Vervolgens heb ik gisteravond de codepages opnieuw aangebracht middels 9-5-7 (bestandsnaam leeggelaten dus alle databases).
Helaas staan de leestekens nog niet goed, zie voorbeeld hieronder.

De logfile van het aanbrengen v/d codepages ook meegestuurd. 1 database kon hij niet openen:
 484 Aanbrengen Codepage op G:FOXLOLOPFLOAA.DBF; The table G:FOXLOLOPFLOAA.DBF could not be opened.

[Peter Stordiau]

Dat hebik al eens gezegd dacht ik ... dan ben je de gegevens aan het invoeren geweest terwijl de codepage fout was ...

Ik weet dat dit vervelend klinkt en is, maar het is niet anders (en verder een k-onderwerp).

[Robert Hekkers]

Dit is inderdaad het geval geweest. Alle 'oudere' gegevens met namen als Mariëlle, Thérèse en André zien er goed uit.

[pascal]

Akkoord. Dan ligt het aan onze werkwijze.
Maar nu wil ik de leestekens weer goedzetten - kun je aangeven wat de juiste werkwijze is? (soms doen we het via ALT-kodes, soms via CTRL-leesteken-letter). Dan gaan we op de aangegeven manier de foute leestekens aanpassen en kijken hoe het dan gaat.

Ik gebruik zelf trouwens onderstaande ASCII-tabel:

[Robert Hekkers]

Nee pascal, het ligt niet aan jullie werkwijze. Het ligt aan het invoeren van gegevens terwijl de database een onjuiste codepage had. Dus je kunt gewoon de gegevens invoeren zoals je dat altijd hebt gedaan.

[pascal]

Ok. Ik moet dus opletten of de codepages in orde blijven. Voor zover ik weet kan deze veranderen wanneer ik een update van Test > Produktie overzet. Zijn er nog meer situaties waarbij ik de codepage moet controleren?

Verder viel me op dat, wanneer ik remote inlog (en niet de console op de server overneem), het aanbrengen van de codepages zo'n 4-5 uur duurt. Kan ik dit versnellen? Misschien een beperkt aantal databases opgeven bij het aanbrengen van de codepages?
Ik zal de volgende keer sowieso rechtstreeks op de console v/d server inloggen, kijken of dat veel uitmaakt.

[pascal]

Gisteren werd gemeld dat van 1 relatie de leestekens niet goed staan (zie hieronder).
Hierop heb ik gisteravond via 9-5-7 de codepages opnieuw aangebracht (alle bestanden). Wel in de DOS-versie van Profit omdat dit vele malen sneller werkt dan in Windows.

Helaas stond het vanmorgen nog fout. Gekke is wel dat bij BAUNUR de leestekens fout staan, bij BAUZOE staat het goed (?).

[Robert Hekkers]

Volgens mij val ik in herhaling: Het ligt aan het invoeren van gegevens terwijl de database een onjuiste codepage had.

Een bestaande fout in een bestand met juiste codepage herstel je niet door nogmaals de codepage aan te brengen...
Dus: gewoon aanpassen, die foutieve tekens.

[Wouter Rijnbende]

Helaas stond het vanmorgen nog fout. Gekke is wel dat bij BAUNUR de leestekens fout staan, bij BAUZOE staat het goed (?).

Tsja... Zie Peter's eerdere opmerking:

Dat hebik al eens gezegd dacht ik ... dan ben je de gegevens aan het invoeren geweest terwijl de codepage fout was ...

Ik weet dat dit vervelend klinkt en is, maar het is niet anders (en verder een k-onderwerp).

Kortom, eerst ervoor zorgen dat de Codepage erop zit, dan de betreffende Relaties wijzigen. Daarna zou het goed moeten zijn (en blijven).

(Oops, Robert had inmiddels ook al gereageerd).

[Wouter Rijnbende]

Daarna zou het goed moeten zijn (en blijven).

Ik mag aannemen dat je na de eerste melding (en reakties van ons) de Codepages hebt aangebracht. Als je nú dus wéér een situatie zou hebben veroorzaakt dat er geen Codepage op de tabel staat, heb je dus ergens een handeling uitgevoerd die die Codepage eraf zou hebben gehaald. Als het goed is krijg je dit binnen Profit niet voor elkaar (maar als je buiten Profit om in de database zou lopen harken, vast wel).

Voor de hand liggender is w.s. dat je in mei 2008 misschien wel de codepages hebt aangebracht, maar je Relatietabel nooit hebt gekorrigeerd op verkeerde leestekens die ontstaan waren door invoering met een verkeerde codepage. In dat geval stond de codepage goed, staat ze nu nog steeds goed, maar kijk je gewoon naar dezelfde fouten die er in mei waren (maar die je nooit hebt opgelost).

Nb: Wel even uitzoeken welke situatie het betreft, immers als je "iets" doet waarmee je de codepage van de tabel af weet te krijgen zou je bezig blijven 

[pascal]

Nb: Wel even uitzoeken welke situatie het betreft, immers als je "iets" doet waarmee je de codepage van de tabel af weet te krijgen zou je bezig blijven 

Achterhalen welke situatie het betreft vind ik lastig. Maar ik zal bij twijfel (bv wanneer ik kontrakten herbereken) gewoon voor de zekerheid de codepages opnieuw aanbrengen. Ik neem aan dat dit gewoon via ProfitDOS mag ivm de snelheid?
De fouten die er nu nog inzitten pas ik handmatig aan.

[Wouter Rijnbende]

Achterhalen welke situatie het betreft vind ik lastig.

Hoeft helemaal niet zo lastig te zijn hoor... Je zegt nú immers dat je de fouten die er nu inzitten eruit gaat halen... Als je zeker weet dat je dat in mei ook gedaan hebt, zitten er nu weer nieuwe fouten in. Als je in mei niet alle fouten eruit hebt gehaald, zit je gewoon naar oude fouten te kijken.

[pascal]

Ik zal de relaties nogmaals checken op fouten en vervolgens voor mijn eigen controle een query van de LORE-database maken (en de waarden opslaan). Wanneer ik de volgende keer twijfel of een fout een oude fout is of niet, kan ik 'm aan de hand van de backup checken.

[Wouter Rijnbende]

en vervolgens voor mijn eigen controle een query van de LORE-database maken

Dit ruikt naar "buiten Profit om". Buiten Profit om kunnen wij niet garanderen dat de codepage erop blijft !

[pascal]

Ik maak regelmatig queries in Excel om gegevens uit Profit te halen, maar niet om gegevens te wijzigen en weer in Profit te schieten (ik zou zelfs niet weten hoe; we gebruiken alleen de inschiet-functionaliteiten voor prijslijsten etc die in Profit zelf zitten).

Dit kan toch geen kwaad hoop ik?