Verwerken sleutelwijzigingen - geblokkeerde funktie (SYCKDO)

[pascal]

Afgelopen zaterdag wilde ik een aantal sleutelwijzigingen doorvoeren (8 artikelen).
Helaas kreeg ik een geblokkeerde funktie tijdens het doorvoeren van de sleutelwijzigingen in de Test-omgeving.

Ik heb HeartProfit Test-omgeving opnieuw gestart, nogmaals gecontroleerd of er niemand in HeartProfit zit, gereorganiseerd TBC en nogmaals geprobeerd de sleutelwijzigingen door te voeren.
Helaas kreeg ik opnieuw een geblokkeerde funktie.

Hierop heb ik een aantal schermafdrukken gemaakt van de geblokkeerde funkties en de log van de sleutelwijzigingen.
Vervolgens de backup teruggezet, waarbij de sleutelwijzigingen al zijn toegevoegd aan menu 9-5-5-1 ('uit te voeren sleutelwijzigingen').

Wat ik anders heb gedaan dan de vorige keren is dat ik de uit te voeren sleutelwijzigingen heb toegevoegd in de Produktie-omgeving en vervolgens de produktie-bestanden heb gekopieerd naar de Test-omgeving.
Dit ook omdat er nu een aanpassing in HeartProfit zit waarbij (als ik het goed begrijp) in geval van artikel-id's de sleutels worden gereserveerd zodat ze niet toegevoegd kunnen worden voordat de sleutelwijzigingen zijn doorgevoerd.
Zie topic http://ha1.heartprofit.nl/profit/index.php?topic=24754.0

Zodoende hoeft ik, wanneer ik de wijzigingen ook in Produktie wil uitvoeren, de sleutels niet opnieuw toe te voegen.
Mocht dit niet verstandig zijn, dan doe ik het de volgende keer weer op de 'oude manier' en voeg ik ze eerst in Test toe en na testen v/d wijzigingen in Produktie.

Omdat de backup is teruggezet is dit helaas niet allemaal meer zichtbaar, maar ik wilde geen risico's lopen en heb netjes de backup teruggezet.
(Backup is van de situatie voor het uitvoeren van de sleutelwijzigingen, maar van na het toevoegen van sleutelwijzigingen in Produktie en de prod.bestanden kopieren naar Test-omgeving.)

Kunnen jullie nog achterhalen waar het fout is gegaan ahv dit verhaal en de schermafdrukken?
En is het verstandig om de sleutelwijzigingen in Produktie te zetten voordat de bestanden naar test worden gekopieerd? Bij twijfel doe ik 't de volgende keer nl liever niet.

[Wouter Rijnbende]

Oorzaak van de geblokkeerde funktie is gevonden en verholpen. Aanpassing staat al op jullie systeem (in de vorm van een gewijzigde Systeemprocedure, waarvoor je even opnieuw Profit dient op te starten). Je kunt het opnieuw proberen.

Kwa procedure...

Het is sowieso verstandig om Produktie- naar Test te kopieren alvorens je je sleutelwijzigingen gaat testen, immers de om te nummeren sleutels hoeven in de test niet te bestaan c.q. in gebruik zijn.

Als je in de Testbestanden omnummert, heb je de mogelijkheid om omnummeren in de SY database over te slaan. Aangezien je normaliter Artikelen of Relaties omnummert, en deze bijna niet in SY voorkomen, kun je SY in de test overslaan, waardoor je gewoon kunt omnummeren terwijl iedereen in Produktie bezig is.

Je hebt géén gescheiden omnummer definities voor Test- en Produktie. Dus, al zet je je definities in Produktie erin, en voer je ze daarna in Test uit, je opdrachten zijn dan 'verwerkt' en ben je vervolgens ook kwijt voor verdere verwerking in Produktie. 
Het enige wat je daarbij zou kunnen helpen is voor het omnummeren een backup-/kopie te maken van \FOX\SY\SYPF\SYCK.DBF (Sleutelwijzigingen) en \FOX\SY\SYPF\SYCL.DBF (Logfiles Sleutelwijzigingen), en die later weer terug te halen (en opnieuw reorganiseren).

[pascal]

Je hebt géén gescheiden omnummer definities voor Test- en Produktie. Dus, al zet je je definities in Produktie erin, en voer je ze daarna in Test uit, je opdrachten zijn dan 'verwerkt' en ben je vervolgens ook kwijt voor verdere verwerking in Produktie.

Ok, dan heeft het dus niet zoveel zin ze in Produktie te zetten en mee te kopieren naar de Test-omgeving.

Ik vink 'SY database overslaan' trouwens nooit aan (gezien de waarschuwing in de helptekst), maar zal onthouden dat dit vwb artikelen en relaties wel kan.
Ga het opnieuw proberen en de gewijzigde sleutels controleren.

Het enige wat je daarbij zou kunnen helpen is voor het omnummeren een backup-/kopie te maken van \FOX\SY\SYPF\SYCK.DBF (Sleutelwijzigingen) en \FOX\SY\SYPF\SYCL.DBF (Logfiles Sleutelwijzigingen), en die later weer terug te halen (en opnieuw reorganiseren).

Moet ik in dat geval reorganiseren TBC of alle bestanden reorganiseren middels 9-5-1, ALL? In het laatste geval voeg ik ze handmatig wel toe, dan ben ik sneller klaar. Toch bedankt voor de tip

Ik laat sowieso weten of het gelukt is, bedankt voor de snelle service!

[Wouter Rijnbende]

Ik vink 'SY database overslaan' trouwens nooit aan (gezien de waarschuwing in de helptekst), maar zal onthouden dat dit vwb artikelen en relaties wel kan.
Ga het opnieuw proberen en de gewijzigde sleutels controleren.

Ik zeg niet dat ik gekontroleerd heb of Artikelen of Relaties in SY voorkomen, maar, ik kan me er weinig bij voorstellen.

Zou je een tekstsearch in de SY database doen naar je om te nummeren sleutels, dan vind je snel genoeg antwoord. Een van de dingen die je wél zult kunnen vinden zijn de logfiles van Change-Key (van een eerdere omnummering). Ha, en tegenwoordig wellicht Multi Media Buttons of Uservariabelen...
In kombinatie met omnummeren in Test (in Produktie kun je hem niet eens uitzetten) zou ik er toch voor kiezen.
Al was het maar omdat de SY bestanden niet gescheiden zijn voor Test- en Produktie, en al zou je een Artikel om te testen in de Testbestanden omnummeren, dan nummer je hem in SY wel echt alvast voor de Produktiebestanden om.

[Wouter Rijnbende]

Het enige wat je daarbij zou kunnen helpen is voor het omnummeren een backup-/kopie te maken van \FOX\SY\SYPF\SYCK.DBF (Sleutelwijzigingen) en \FOX\SY\SYPF\SYCL.DBF (Logfiles Sleutelwijzigingen), en die later weer terug te halen (en opnieuw reorganiseren).

Moet ik in dat geval reorganiseren TBC of alle bestanden reorganiseren middels 9-5-1, ALL? In het laatste geval voeg ik ze handmatig wel toe, dan ben ik sneller klaar. Toch bedankt voor de tip

Van die 2 tabellen een backup maken, die 2 tabellen terugzetten, en die 2 tabellen reorganisen.

Ofwel, 1 keer  9-5-1-SYCK
en 1 keer 9-5-1-SYCL

[pascal]

Ok - ik heb nu genoteerd dat 'SY database overslaan' in Test wordt aangevinkt, in Produktie niet.
En na invullen sleutelwijzigingen SYCK.DBF + SYCL.DBF backuppen, na testen wijzigingen in Test-omgeving terugzetten in Produktie en vervolgens deze bestanden reorganiseren.

Ik laat wel weten of alles gelukt is.
Bedankt voor de service.

[Wouter Rijnbende]

Succes. 

[pascal]

De sleutelwijzigingen heb ik nogmaals doorgevoerd in de Test-omgeving. Dit keer geen geblokkeerde funktie.
Er is nog wel 1 tabel in Test waarin de 'oude' artikelcode nog wordt gevonden.
Dit is tabel LOCC.DBF

Hierin komen de volgende artikelcodes nog voor, zie ook schermafdruk:
BTMBD15308GRIJK
BTMBD15308ROODK
BTMBD30308GRIJK (zie schermafdruk)
BTMBD30308ROODK

Ik kan me niet herinneren dat ik eerder in LOCC.DBF nog oude sleutels vond.
Ik heb de wijzigingen laten staan in de Testomgeving. Kun je hier eens naar kijken?

[Wouter Rijnbende]

Als ik daar die twee ~~ met een * voor zie staan, vermoed ik dat dit 'verwijderde records' zijn.
Maar, ik zal het even expliciet kontroleren.

[Wouter Rijnbende]

Inmiddels staan er geen deleted records (meer?) in die tabel, en de waarde die je noemt komt ook niet voor.
Kan het zijn dat je na je tekst search alsnog gereorganiseerd hebt ?

[pascal]

Kan het zijn dat je na je tekst search alsnog gereorganiseerd hebt ?

Dat is het - heb eerst text-search gedaan en daarna gereorganiseerd. Dat is fout gegaan, excuses (had even niet aan de deleted records gedacht).
Een nieuwe text-search vindt de waarde BTMD15308GRIJK niet terug in de Test-bestanden. Denk dat dit dan ook voor de rest geldt.

Volgens mij gaat de rest goed en kan ik komend weekend een nieuwe poging doen om de sleutelwijzigingen in Produktie uit te voeren.

[Wouter Rijnbende]

Ook weer verklaard.

[pascal]

Bedankt voor de hulp. Wanneer je niks weer hoort is het goed gegaan afgelopen weekend 

[Wouter Rijnbende]

afgelopen weekend