probleem sleutelwijzigen

[mdekraa]

Ik heb TOSH000290 omgezet naar TOSH100130

Bij controle is gebleken dat alle teksten die gekoppeld waren aan de keuringen (LOARKVRA) en die gekoppeld waren aan de receptregels (LORTTDRA) niet zijn omgezet naar het nieuwe artikelnummer.

Kunnen jullie hiernaar kijken aub.

in ieder geval wordt de APTX_KEY in LOUX en LOBX niet goed herkend, hier staan de teksten nog met
"ADPROD     TOSH000290     A003C" en "ADPROD     TOSH000290     6612AM    5" als sleutel

Ik kan eventueel wel browsen en wijzigen maar voordat ik zoiets doe heb ik graag even dat jullie het controleren ivm de gekoppelde sleutel verwijzingen

[Wouter Rijnbende]

Probleem is opgelost, staat inmiddels op jullie systeem.
Van mij mag je nu browsen; bedankt voor het even laten staan!

[mdekraa]

behalve de 2 genoemde tabellen, moet ik nog meer plaatsen controleren?

PS: Off topic:
Hoe gaan jullie hier op termijn mee om, Ik bedoel dus de velden waar 3 sleutels gecombineerd worden tot 1 unieke sleutel.
Database technisch voel ik er op termijn toch meer voor als dat (ooit) overgaat naar een "normale" veldenstructuur waar een sql achtige statement de sleutel bepaald.
Dit ook met zicht op later overzetten van a;lle tabellen naar SQL of Oracle (ja ik geloof Peter nog steeds als hij meld dat het andere database management systeem er aan komt)
Dat betekent echter wel deat de "roeleveld" in de prullenmand moet...
En daarmee is een van de oudste nog draaiende modules dan om zeep geholpen?
 

[Peter Stordiau]

Marco, ik dit geval kan dat niet anders. Er zijn hier procesmatige zaken aan de orde die ertoe leiden dat die sleutel is gekombineerd. Is misschien ook wel de enige uitzondering, maar het is ook niet anders.

Trouwens, als je zodirekt inderdaad met SQL aan de gang gaat heb je heus nog wel meer te doen op het procesmatige vlak hoor. Valuta omrekening en zo.

Zo, dan ga ik nu weer verder met SQL

[Wouter Rijnbende]

behalve de 2 genoemde tabellen, moet ik nog meer plaatsen controleren?

Ja hoor, alle 1498 overige tabellen (kan er een paar honderd naast zitten).

Voor het geval je de producere niet meer weet:

a. eerst produktie- naar test kopieren
b. dan in test je sleutelwijziging uitvoeren
c. vervolgens met een text search opdracht in de testfiles zoeken naar je omgenummerde voorkomens

Pas als dit lukt, mag je ervanuitgaan dat de omnummering in produktie het ook zal doen.

Nb: En ja... ik weet dat dat geen doen is. 

[mdekraa]

o trouwens:
sinds Windows XP werkt text search niet meer.
(lees maar eens na op internet fora)
Windows XP doet alleen nog maar "slim zoeken" (niet dus)

[Peter Stordiau]

Enig idee waar je het over hebt ?

[mdekraa]

ja,

http://support.microsoft.com/kb/309173

er zijn trouwens free tools welke het sleutelen in het windows register niet nodig maken.
Een klein en elegant pakketje is:
http://www.mythicsoft.com/agentransack/Page.aspx?page=download

[Peter Stordiau]

Tjongejongejonge ... verwijs je eerst naar een kb artikel van 2001 en of we even een SP willen installeren (zal wel 1 moeten zijn). Ik dacht al dat je misschien Vista bedoelde, maar ik begrijp dat je net over bent van W2K ...

Vervolgens komt er een eureka pakketje op de proppen uit 2003. Ja, werkt misschien wel.

... Wat jij alleen niet door had (hoe kon je het ook weten) is dat als wij verwijzen naar "Text Search" dan bedoelen wij TS.EXE uit naar grove schatting 1980. Hahaha. Die staat in c:\heart\tools, tenzij je dat hebt weggegooid. Werkt prima, vindt alles, kan alles.


Maar als je je echt wilt vermaken met text search achtige zaken, moet je toch op Vista zijn.
Als je het een beetje doorhebt, dan het vriendelijke verzoek om er ook even een handleiding van te maken, zodat we er allemaal profijt van hebben.

[mdekraa]

Helemaal mee eens, maar naar ervaring: Windows Sp's installeren lost dit niet op.
Onze vriendelijke vrienden in de US willen gewoon dbf files niet zien als "te handlen files"

dus inderdaad TS of dat tooltje...

[mdekraa]

behalve de 2 genoemde tabellen, moet ik nog meer plaatsen controleren?

Voor het geval je de producere niet meer weet:

a. eerst produktie- naar test kopieren
b. dan in test je sleutelwijziging uitvoeren
c. vervolgens met een text search opdracht in de testfiles zoeken naar je omgenummerde voorkomens

TROUWENS 2 PUNTJES VERGETEN:
b'. Na sleutelwijzigen bestanden reorganiseren, anders kan het zijn dat je nog oude niet gepurgde records tegenkomt die de desbetreffende sleutel nog wel bevatten...

b''. Delete alle oude ubk files of kijk alleen naar bestanden van het type *.dbf



Trouwens: reden van de post: de nieuwe versie neemt inderdaad netjes de complexe sleutels mee in de text files.
Met dank

[Peter Stordiau]

b' : Goed punt Marco. Als dat niet in de helptekst staat, zetten we dat erbij.

[Wouter Rijnbende]

Helptekst is uitgebreid.

Nb: Ook even met het voorbehoud dat de Tekstsearch opdracht nooit 100% zekerheid zal kunnen geven. De omgenummerde sleutel kan in theorie elders ook als sleutel voorkomen (of in een omschrijvingsveld). Als we zowel een Artikel '000001' alsmede een Relatie '000001' hebben, en we gaan de Relatie omnummeren, dan zal de Tekstsearch aksnog de waarde '000001' in het Artikelbestand kunnen vinden, hetgeen niets zegt over het feit dat dit daar als Artikelnummer danwel als Leverancier of i.d. toegepast is.

[Wouter Rijnbende]

Voor het geval je de producere niet meer weet:

a. eerst produktie- naar test kopieren
b. dan in test je sleutelwijziging uitvoeren
c. vervolgens met een text search opdracht in de testfiles zoeken naar je omgenummerde voorkomens

Pas als dit lukt, mag je ervanuitgaan dat de omnummering in produktie het ook zal doen.

Nb: En ja... ik weet dat dat geen doen is. 

Tussen b en c. mag nog een 3e regel worden ingevoegd: Bestanden Reorganiseren, opdat de Tekst Search niet met resultaten uit deleted records komt.