sleutelwijzigingen - velden die niet gewijzigd worden

[pascal]

LOZX en LOAX zijn inmiddels opgelost, zie http://ha1.heartprofit.nl/profit/index.php?topic=23845.0
Dit zal in je eerst volgende Upgrade zitten.

Deze tabellen waren "relatief simpel" omdat we al een mechanisme hebben voor "tekstbestanden bij een entiteit";
de oplossing van LOUW zal wat langer op zich laten wachten.

Ok mooi, dan kan ik dat gelijk testen wanneer ik bij de volgende update opnieuw Produktie > Test kopieer.
Voor de rest wacht ik weer af. Ik snap ook wel dat niet alles in 1x gefixt kan worden, maar zolang er voortgang in zit ben ik allang blij

[pascal]

In februari heb ik in de Test-omgeving opnieuw een aantal sleutelwijzigingen uitgevoerd, als test. Deze wil ik allemaal in de toekomst overzetten, vandaar dat ik nieuwsgierig was naar waar het evt nog mis gaat op dit moment.
Onze laatste update is van 22-11-2012 volgnr 23739.

Onderstaande artikelen (LOAR_AID) heb ik omgezet in de Test-omgeving:

Oude waarde:   Nieuwe waarde:
DFMK8BRUIK   DFMK8SIERK
DF8KFGRIJK    DF8KFGRBAK
DFMK8GRIJK   DFMK8GRBAK
VBT303045GRIJK   VBT303045GRIJ
71513GRIJ   71513GRIJK
VB13151025GEBDK   VB1315G1025GEBD
VB13151025ZWKV   VB1315G1025ZWKV
VB13151025GRIJS   VB1315G1025GRID
VB10251315GEBDK   VBG10251315GEBD
VB10251315GRIJS   VBG10251315GRID
DF8GECAK   DFN8VESUK
DF8BRUIK      DF8SIERK

Zie schermafdrukken voor de gevallen waarin ik de oude waardes nog tegenkom.
Wanneer deze waardes in bv teksten voorkomen heb ik deze eruit gefilterd, voor zover ik ze herken.
Igv tabel LODA komt de identiteit in voor in LOSU_SID "/1BBB-BETON" en betreft het oude prijs/kortingsafspraken (2000/2001). Misschien zijn die dus niet erg relevant.

[Wouter Rijnbende]

LOBH is een bestand met Elementaire Behoeftes. Deze tabel wordt tegenwoordig helemaal niet meer gebruikt, en je kunt het vullen van die tabel met een behoefterunparameter ook uitschakelen.

LODA / 1BBB-BETON. Inderdaad, de bedrijfs-id komt niet overeen, en dus logisch dat deze niet omgenummerd wordt.

LOLR zou in principe gewoon moeten werken. Kun je bij deze records een kijken wat de LROPEN indikator bevat?

LOUW / Uservariabelen; was al bekend.

PKAG. Agenda / Afspraken. En zo te zien iets wat uit een Prijs of een Kontrakt is gegenereerd?

Leuk zo'n module waarmee we proberen te doen wat in heel automatiseringsland niet is toegestaan :-)

[pascal]

LOBH is een bestand met Elementaire Behoeftes. Deze tabel wordt tegenwoordig helemaal niet meer gebruikt, en je kunt het vullen van die tabel met een behoefterunparameter ook uitschakelen.

LODA / 1BBB-BETON. Inderdaad, de bedrijfs-id komt niet overeen, en dus logisch dat deze niet omgenummerd wordt.

Ok, die kan ik dus negeren.

LOUW / Uservariabelen; was al bekend.

Klopt, geen nieuws wat dat betreft (had 'm weg kunnen laten voor het overzicht).

LOLR zou in principe gewoon moeten werken. Kun je bij deze records een kijken wat de LROPEN indikator bevat?

LROPEN staat voor alledrie op 'N'.

PKAG. Agenda / Afspraken. En zo te zien iets wat uit een Prijs of een Kontrakt is gegenereerd?

Vind ik moeilijk om te achterhalen, ga ik verder naar kijken.

Leuk zo'n module waarmee we proberen te doen wat in heel automatiseringsland niet is toegestaan :-)

Ja - en als het bestaat dan ga je het nog gebruiken ook...

[pascal]

Ik wil graag een update aanvragen - kan ik de gegevens in de Test-omgeving overschrijven? Of is het voor de changekey handig dat de gegevens beschikbaar blijven?
De gevonden waardes PKAG kan ik niet 1-2-3 terugvinden in de Test.

Bvd!

[Wouter Rijnbende]

Je hebt de voorbeelden duidelijk beschreven, dus ik denk dat we dat wel moeten kunnen reproduceren;
laat het i.i.g. geen Upgrade-aanvraag tegenhouden.

[pascal]

Ok, graag bij deze dan  . Bij voorbaat dank! > ik heb even apart een aanvraag voor een upgrade gedaan, ivm het overzicht.

[pascal]

PKAG. Agenda / Afspraken. En zo te zien iets wat uit een Prijs of een Kontrakt is gegenereerd?

Ter info: deze ben ik uiteindelijk tegengekomen, waardes staan onder menu 2-9-4-6-1
Bv van gebruiker GTH, zie schermafdruk hieronder.
We gebruiken de agenda trouwens verder niet actief (gebruiker kent de funktie zelfs niet).

[pascal]

PKAG. Agenda / Afspraken. En zo te zien iets wat uit een Prijs of een Kontrakt is gegenereerd?

Ter info: deze ben ik uiteindelijk tegengekomen, waardes staan onder menu 2-9-4-6-1
Bv van gebruiker GTH, zie schermafdruk hieronder.
We gebruiken de agenda trouwens verder niet actief (gebruiker kent de funktie zelfs niet).

Ik wil graag DFMK8BRUIK en DFMK8GRIJK omzetten.

Voor deze 2 artikelen worden de waardes in tabellen PKAG en LOUW niet omgezet.
Vwb LOUW willen we het oplossen door de waardes handmatig aan te passen.
De PKAG is voor zover ik kan beoordelen de tabel met kontakten in de persoonlijke agenda - wanneer we deze niet gebruiken, kan het dan kwaad de 2 artikelen om te zetten?

[Wouter Rijnbende]

De records voor PKAG blijken uit Funktie Triggers te komen. Funktie Triggers kun je niet alleen gebruiken om een email mee te verzenden als er een bepaalde funktie wordt uitgevoerd, er is ooit ook een optie opgenomen om een trigger via een formele Agenda (Profit-Workflow) te laten lopen.

Zo te zien hebben jullie daar vorig jaar een tijdje mee getest bij Kontrakten. Inmiddels staan alle Funktietriggers zodanig ingericht dat ze niet via de Agenda lopen, maar in de periode tot 29 april 2011 zijn er diverse Agenda punten als gevolg hiervan gegenereerd. Ik sluit niet uit dat er in die hoek ook iets niet werkt of verkeerd is ingericht, want, gezien soms talloze dubbele sleutels bij Kontakt-Deelnemers, vermoed ik dat e.e.a. nog wel eens in een loop heeft gezeten.

Zojuist (tel. overlegd) derhalve alle Afspraken en Afspraakdeelnemers van deze Funktie Triggers eruit gegooid. Dit alleen in Produktie. Tabel is overigens ook niet gereorganiseerd (er zitten mensen in), dus, een Tekst Search zal nog steeds wat vinden in deze tabel, maar dat kun je negeren. Er zal in PKAG niets meer hoeven te worden omgenummerd.

Resteert dus LOUW, en daarvan gaf je aan die zelf te doen.

[Wouter Rijnbende]

Ik hoop dat je nog even geduld kan hebben. Maar dan nog moet je er rekening mee houden dat het alleen om die User Variabelen kan gaan hoor ...
Volgens mij vind je dat al minder leuk.

Per heden is Profit-Change-Key zodanig aangepast dat deze nu ook omnummert in User Variabelen en tevens in Multi Media Buttons (http://ha1.heartprofit.nl/profit/index.php?topic=24510.0).

E.e.a. vereist een Upgrade.

[pascal]

Dat is goed nieuws!
Volgens mij zijn er nu geen tabellen meer die nog problemen geven (?).

Dan ga ik na de bouwvak voorzichtigaan ook weer een aantal relaties omzetten

[pascal]

Onderstaande artikelen (LOAR_AID) heb ik omgezet in de Test-omgeving:

Oude waarde:   Nieuwe waarde:
71513GRIJ   71513GRIJK
VB10251315GEBDK   VBG10251315GEBD
VB10251315GRIJS   VBG10251315GRID
VB13151025GEBDK   VB1315G1025GEBD
VB13151025GRIJS   VB1315G1025GRID
VB13151025ZWKV   VB1315G1025ZWKV
 en:
283026IVBLHARD   283026IBLHARD
283026IVBRHARD   283026IBRHARD
283026IVBTHARD   283026IBTHARD

Die eerste 6 heb ik al eerder in de Test-omgeving omgezet en de problemen gemeldt.

Het goede nieuws: controle van de databases (.DBF) op het voorkomen van de oude waardes leverde voor nog maar 1 artikel een probleem op:

In Test is 71513GRIJ omgezet in 71513GRIJK.
Controle leert dat de waarde 71513GRIJ nog voorkomt in \LO\LOTF\LOLR.DBF, en het zijn exact dezelfde 3 waardes als in de post Reply #16 on: February 28, 2012, 02:17:24 pm

Zie ook schermafdruk hieronder - in het raadpleegscherm staat nog het oude artikel, terwijl deze bij de artikelen zelf niet meer voorkomt.
Ik heb uiteraard de Produktie-bestanden naar de Test-omgeving gekopieerd voordat ik de sleutelwijzigingen heb uitgevoerd in de Test-omgeving.

[Wouter Rijnbende]

Ik denk dat die LOLR situatie er bij ingeschoten is. Lees ook nergens dat daar iets voor is aangepast, terwijl deze wel fout gaat.
Ga ik naar kijken.

[Wouter Rijnbende]

Ik heb de situatie hier na kunnen doen, en ik denk dat ik hem opgelost heb.

De aanpassing staat al op jullie systeem.

Ik heb tevens een nieuwe Sleutelwijzigingsopdracht erin gezet, waarmee de 71513GRIJK weer even teruggenummert wordt naar 71513GRIJ. Als je die uitvoert, en daarna opnieuw 71513GRIJ omnummert naar 71513GRIJK, doet hij als het goed is wel alles.