Heart-Profit ERP

We hebben een aantal artikel-id's (LOAR_AID) aangepast. Menu 9-5-5-2.

Hierin is bij 1 artikel iets fout gegaan: we hebben 182025U3GRIJE omgezet naar 182025U3GRIJK.
De 182025U3GRIJK stond er echter al in. Nu zijn er 2 stuks van dit artikel aanwezig.
Kunnen jullie dit oplossen? Degene met omschrijving !!!NIET MEER GEBRUIKEN!!! mag eruit.

Bij voorbaat dank,
Pascal

We hoeven je testbestanden toch niet recht te browsen?  :wink:

Je gaat me toch niet vertellen dat je ongetest e.e.a. rechtstreeks in de Produktiebestanden hebt uitgevoerd  :(

Deze glipte er door... hij is wel omgezet met de juiste gegevens, maar naast eenzelfde met deze code.
Normaal gesproken zet je niet een artikelcode om naar 1 die al in het systeem staat. Hier toch gebeurd...

ik dacht dat dat onmogelijk was binnen de programmatuur?

In het verleden heb ik n.l. wel eens gevraagd of het mogelijk was om de data van 2 artikelen of 2 relaties samen te voegen en toen werd er gemeld dat dat niet mogelijk was....

Dat is dus ook niet mogelijk (als het goed is), want daar zit een kontrole op.

OOk frappant, en dat zou mijn volgende vraag zijn, hoelang staat de omschrijving van de 2e regel op "NIET GEBRUIKEN"?

Immers, áls je een dubbele hebt, kun je het 2e voorkomen uit de tabel niet wijzigen.

Tsja... en kontroles worden omzijld als iemand de Sleutelwijzigingen niet zelf toevoegt, maar iemand hier o.b.v. een aangeleverd lijstje e.e.a. klakkeloos als Sleutelwijziging opneemt  :smack:; hoe goed bedoelt ook.

Vervolgens is e.e.a. niet getest in de Testbestanden  :smack:

Tsja... en nu...

Je dubbele Artikelnummer heb ik eruit gehaald  :yahoo:

Maar ja... wat je nú allemaal voor een ellende over hebt...  :scare:
ik hoop dat het te overzien is, anders moet ik een woord in de mond nemen welke met een 'B' begint en op 'ackup' eindigt. :(

Om te beginnen de Artikel-/Verschijning, waarvan je er nu 2 hebt.

Ik laat het maar even aan jullie over aan degene die de Sleutelwijzigingen voor jou erin gebrowsed heeft...

:13c:

Ik heb hem wel gedraaid in Testbestanden.
Maar omdat het om veel artikelen ging, heb ik de sleutelwijzigingen in laten schieten, deze werden vervolgens zichtbaar onder 9-5-5-1 Raadplegen Sleutelwijzigingen. Wat is het verschil met zelf handmatig via 9-5-5-1, F4 de artikelcodes stuk voor stuk in te geven?

Test leek trouwens goed te gaan, flink aantal artikelen gecontroleerd die allemaal goed gingen.
Het lijkt echter fout te gaan bij dit soort uitzonderingen als deze (artikel omzetten naar een artikelcode die al bestaat)...
Ik denk (hoop) dus dat alleen voor deze uitzonderingen er problemen onstaan zijn.

Maar wel bedankt voor het verwijderen van de doublure.

Wel gedraaid in test, maar niet getest...


Er zou geen verschil moeten zijn tussen handmatig of via een konversie. Bij de konversie is (onterecht blijkt nu ) als uitgangspunt genomen dat hetgeen jij aangeleverd hebt goed was.


Oops... je verwacht nog meer situaties te hebben ?


Je bent er nog niet ! Pas maar op dat we de boel nog kunnen herstellen...

Ik kom zojuist deze nog weer eens tegen, en konstateer dat het een beetje op een doodgebloed einde lijkt. Niets is minder waar;
Diverse mensen in den lande hebben op punt van ontslag (nemen, geven, dan wel krijgen) gestaan, komplete weekends zijn verworden tot uitgeregende trappelzakken (of hoe heet zo'n tenue waarmee je geen kwaad behoort te kunnen doen), echte - of zich zo noemende experts hebben getracht de mathematisch onomkeerbare puzzel the ontsluieren, mensen hebben spontaan hum mobieltjes in de plomp gegooid ...

Maar iets als dit kan maar beter nooit meer gebeuren. In elk geval niet als je 3 dagen na dato erachter komt dat e.e.a. niet helemaal is geslaagd (kwa ChangeKey) en je dus terug zou moeten naar een backup van 3 werkdagen eerder.

Achtergrond info voor eenieder (inklusief wij zelf) die meent dat iets als dit wel meer of slechts iets minder laconiek kan worden behandeld :

Men neme een willekeurige lijst (eigen vertaling) van produkten die je eigenlijk liever niet meer gebruikt; je geeft ze een ander Artikelnummer om moverende redenen (moverend is altijd een ietwat moeilijk woord, maar wordt in de juridische omgeving vooral gebruikt om aan te geven dat je nu eenmaal hebt gedaan wat je hebt gedaan en dat het JOU geen flikker uitmaakt waarom, en je vooral ook nooit naar de reden moet vragen, waarschijnlijk omdat je dat zelf niet weet, dan wel in tijdelijke staat van ontbinding bent geweest).

Je hebt die module ChangeKey toch, dus je denkt "kom", laat ik eens 2400 Artikelen gaan omnummeren. Vervolgens kom je erachter
dat de hoeveelheid eigenlijk niet is te overzien, dus je gebruikt dezelfde spreadsheet als waar je de oude meuk op vond, geeft deze aan Heart met de vraag of wij die opdrachten er op elektronische wijze in kunnen krijgen. "Tuurlijk, wij kunnen alles".

Zo gezegd do gedaan, en nadat de opdrachten erin staan hoeft de gebruiker nog slechts op F1 te duwen, om het systeem het werk te laten doen van het omnummeren. Tuurlijk doe je dit in de Testbestanden, want dat is immers voorschrift. Uiteraard kan je niet *alles* kontroleren, want dat is veulsteveul. En dus de handel ook maar in Produktie.

Twee dagen later konstateert iemand 2 keer hetzelfde Artikelnummer in het systeem, en geeft de opdracht om dit snel even op het forum te plaatsen; Heart weet daar wel raad mee.

Goed, wat hier verder dus niet is uitgeschreven, is dat de Excel met de erin te schieten opdrachten "fouten" bevatte. Kan gebeuren, en vergissen is menselijk. Het gevolg hiervan echter, is dusdanig drastisch dat het ook niet meer goed kan komen. Dus, in dit geval werd er omgenummerd naar reeds bestaande Artikelnummers, en werd de kontrole daarop niet (meer) uitgevoerd omdat die kontrole zich immers in het betreffende Toevoeg programma bevindt. En, gezien de konstruktie van het geheel kan dit ook in later stadium niet meer. Ze had natuurlijk moeten worden ingebouwd bij de tijdelijke (en "snelle") programmatuur die de Excel in de betreffende tabel in Profit schiet ... maar ja, als je zoiets moet gaan doen wordt iets wat ongeveer kosteloos is ineens heel erg duur, en meestal ook ondoenlijk.
Wel, in dit geval is de hoeveelheid om te nummeren niet alleen te groot om zelf in te typen v.w.b. de opdrachten, ze is tevens te groot om het reëlerwijs te kunnen kontroleren. Daarnaast - en dat is zo logisch als wat - wie gaat er nu kontroleren op een gegeven als "en bestond (!) het Artikelnummer soms al nadat de omnummering heeft plaatsgevonden". Tuurlijk niet, dat had al in eerder stadium moeten gebeuren.

En zo verziek je dus in één kleine handeling je hele database. Althans, als je dit pas merkt nadat de backup van een 3 dagen terug is dan kan je daar met recht over spreken.
Het is onduidelijk wie hiervan nu het meest in de stress heeft gezeten, de klant of wij zelf. Ik denk wij.
Merk ook op dat (dit erop neerkwam dat) dit een situatie was van het veranderen van de woordjes "de" in "een" in een tekst, waarna je vervolgens weer terug wilt naar de oude situatie, en denkt de woordjes "een" in "de" te kunnen veranderen. Dit GAAT ECHT NIET.

E.e.a. is nu "opgelost" door goede afspraken te maken (als er ergens iets vreemds gebeurt dan helpen wij wel) en verder door er pragmatisch naar te kijken, wat in dit geval goed mogelijk is (het betrof 20 reeds bestaande Artikelen die eigenlijk niet meer gebruikt moesten worden).


Goed, ik heb dit maar genoteerd omdat de mate van enerveren (t/m 5 dagen na de oorspronkelijke post) dat wel rechtvaardigt, maar vooral is het een poging om aan te geven dat er NOOIT lichtzinnig gedacht mag worden over ChangeKey en wat ze kan aanrichten. Daarom : Altijd eerst uitvoeren in de Testbestanden (en een verse kopie) *en* alles ook goed kontroleren. Zaken als het kontroleren op dubbele output hoort daar normaliter niet bij, maar ontstaat uiteraard al eerder : het juist bepalen van de nieuwe ID's (niet vergeten, het gaat niet alleen om Artikelnummers, maar theoretisch alles). Wij hebben intussen alles zo goed als mogelijk dichtgetimmerd, ook voor als er nog eens een spreadsheet langskomt in deze. Maar wat het laatste betreft geldt ook voor ons dat we - in het algemeen - niet zo maar zaken moeten inlezen, maar minimaal moeten (trachten te) kontroleren of wat de klant aanlevert wel juist is, en de hele handel niet om zeep kan helpen. Voor zo'n oordeel zou ik rustig twee uur extra rekenen, in plaats van te zeggen "oh, kwartiertje - half uurtje misschien". Starttarief.

:heat:
Peter







Alle hier genoemde of geïmpliceerde personen zijn puur fictief doch berusten wel op een redelijke kern van waarheid.

Bedankt voor het optekenen van dit hele avontuur (avontuur klinkt nog leuk, maar was het zeker niet).
Wij hebben inmiddels ook afspraken gemaakt mbt het gebruik van Changekey in de toekomst. Zo willen we niet meer dan maximaal een tiental id's in 1 keer doorvoeren, mede vanwege hetgeen je zelf al aangeeft (het kunnen overzien & testen van de wijzigingen).

Daarnaast wil ik de sleutelwijzigingen niet meer 'alvast' in Profit zetten om ze later uit te voeren, maar deze pas buiten werktijd toe te voegen, nadat ik eerst een extra backup heb gemaakt van de complete database. Dit voorkomt dat er tussen het toevoegen van de sleutelwijziging en het verwerken ervan stiekem een id wordt toegevoegd (door wie dan ook)welke gelijk is aan de 'nieuwe waarde' van de om te zetten id. Waardoor er weer dubbele id's kunnen ontstaan (the horror.. :blink: ).

Wel goed dat jullie zoveel mogelijk dichtgetimmerd hebben - mocht het niet voor ons zijn dan wel voor andere klanten die met de module bezig gaan  :goodjob:

Voordat iemand daar profijt van heeft, zal er wel eerst nog een Upgradetje nodig zijn;
(voor de zekerheid: jullie beschikken nu dus ook nog niet over die extra kontroles).

Pascal, laat ik er nog aan toevoegen dat er hier niemand is - en ook bij jullie er niemand behoort te zijn - die vindt dat dit jouw schuld is. Dat heb ik je telefonisch al gezegd, en wil ik langs deze weg ook nog wel eens melden.

Maar, zo hebben we aan deze kant Richard die jouw data heeft ingelezen die eveneens niet moet denken dat het zijn schuld is.

Zelf heb ik ooit de ChangeKey programmatuur gemaakt, en misschien had ik moeten bedenken dat er ooit iets als Excel zou gaan bestaan, en dat de kontroles "dieper" moesten dan destijds ontwikkeld. Maar ja, ik moet ook maar niet denken dat het mijn schuld is.

Er zal aan jullie kant iemand zijn die heeft bepaald welk Artikelnummer hoe moet gaan heten. Tja, als je daarin al geen fouten mag maken ... dus die moet ook maar niet de schuld krijgen.

Het is domweg "gevaarlijke" programmatuur, en door een toevallige opeenstapeling van "fouten" gaat het ook echt fout.
Maar je hebt helemaal gelijk : dit een volgende keer niet meer in die hoeveelheden ineens doen, lost eigenlijk alles op. Nou ja, vast wel.

Dank,
Peter

Fijn om dat nog even bevestigd te zien Peter.
Vooral omdat we nog wat tegenkomen in het Verwacht voorraad verloop:

In de kontraktregels staat er een artikel (HAL8GRIJK) welke volledig geleverd is, maar ook nog steeds een volledige voorraad geeft. Zie afbeelding 1. Dit artikel is omgezet (HAL8GRIJ > HAL8GRIJK). Dit is echter niet 1 van de 20 artikelen met de dubbele artikelcode/verschijningsvorm.

Bij de afleveradressen kun je kijken welk materiaal waar geleverd is.
In dit scherm staat nog de oude artikelcode --> hierdoor "ziet" HP niet dat het materiaal reeds geleverd is en daardoor zet HP het materiaal weer op voorraad!! (afbeelding 2).

Er zijn blijkbaar tabellen waar de HAL8GRIJ niet omgezet is naar HAL8GRIJK?
Ik heb uit de logfile van de sleutelwijzigingen alle omzettingen mbt de HAL8GRIJ > HAL8GRIJK gefilterd en deze bijgevoegd (SYCL_HAL8GRIJ.xls). Daarin zie ik geen verdachte dingen staan. Maar misschien dat jullie aan de hand van de tabellen kunnen zien of/welke er niet omgezet zijn?

Voor de goede orde: ik zie de HAL8GRIJ niet meer in het artikelbestand / de recepturen staan.
:17c:

Dit is een van die situaties waarvoor je zo goed moet testen...

In dit geval een fout in Change Key, doch eentje die alleen aan het licht komt bij een bepaald type inrichting: die van jullie  :smile:

Het is nu (o.a. ?) foutgegaan bij LOVR (Verkooporderregels) en LOLR (Raaplijstregels), en wel omdat daar is omgenummerd volgens een index waarbij het om te nummeren sleutelveld (LOAR_AID) getrimd is opgenomen in de index. Op zich hoeft dat geen problemen op te leveren, maar wél als jouw Artikelnummer als linkerdeel voorkomt in een ander Artikelnummer. En, aangezien zoiets gewoon moet kunnen, zal er v.w.b. Change-Key een regel gehanteerd moeten worden dat deze module niet mag omnummeren conform een index waarbij het om te nummeren sleutelveld getrimd is opgenomen in de index.

Konkreet, in de index staat:

HAL8GRIJDDIST (= HAL8GRIJD / DIST)
HAL8GRIJST (HAL8GRIJ / ST)

Change-Key zoekt HAL8GRIJ, en zal als eerste HAL8GRIJD vinden, konstateert dat het Artikelnummer niet voldoet, en bedenkt dat er dan niets omgenummerd hoeft te worden. Fout dus.

Echter, als jouw Artikelnummers HAL8GRIJK / HAL8GRIJD zouden hebben geheten, dan had je dit probleem niet gehad, omdat het ene Artikel niet kwa linkerdeel voorkomt in het andere Artikel.

Ik zal Change-Key aanpassen m.b.t. het niet omnummeren conform indexen waarbij het sleutelveld getrimd is. In een aantal gevallen kan er dan alsnog omgenummerd worden volgens een andere index, in andere gevallen zal dit impliceren dat er niet (meer) via een index kan worden omgenummerd en het omnummeren trager wordt (maar liever traag dan fout).

Nb: Op hoeveel meer plekken dit fout gaat, buiten LOVR en LOLR, weet ik zo niet, maar ik zou zeggen "kontroleer die HAL8GRIJ" maar eens heel goed (bijv. door een Tekst Search naar "HAL8GRIJST" uit te voeren of i.d.).
:17c:

Situatie is overigens vergelijkbaar met de eerder opgetreden ENCDEN en ENCDEN01; zie http://ha1.heartprofit.nl/profit/index.php?topic=21994.0;all

Niet helemaal, omdat dát de situatie is dat er werd omgenummerd via een index waarbij direkt na het bedrijfs-id het om te nummeren veld in de index stond, en dit nét weer een andere kombinatie betreft. Hier staat er een "Open indikator J/N" in de index tussen, en wordt o.b.v. een speciale funktie voor iedere waarde van die open indikator een nieuwe doorloop gegenereerd (beter één keer Ja en één keer Nee doorlopen mét index, dan alles zonder index).

Maar, ook in die situatie mag er dus niet met getrimde velden worden gewerkt.

Ook opgelost (vereist wel een Upgrade).

Ook in tabel LOBH heb ik de HAL8GRIJ nog gevonden in bedrijf BBB-BETON (zie schermafdruk).

De 'foute' codes staan trouwens heel vaak in bedrijf BBB-EURO, welke niet meer gebruikt wordt.
Is het mogelijk dit hele bedrijf uit de database te gooien? Uiteraard alleen wanneer dit geen grote risico's met zich meebrengt.

Een vraagje zonder te kijken : Het is toch niet zo dat er in BBB-EURO ook is omgenummerd ? (ofwel, wat impliceert jouw 'foute' hier ?).

In BBB-EURO is inderdaad niks omgenummerd.
Maar wanneer je een text-search doet in de databases, komen er allemaal resultaten naar voren die in BBB-EURO blijken te zitten. En aangezien we niks met BBB-EURO doen (was om destijds eea te testen bij de overgang naar de euro), mag dat hele bedrijf van ons er ook uit.
Ik hoop dat je snapt wat ik bedoel.

De situatie LOBH zal fout zijn gegaan, omdat de records die hierin staan sowieso niet korrekt zijn; veld ARTYPE is niet gevuld, terwijl ze dat wel zou moeten zijn. Nu bevat LOBH de Elementaire Behoeftebasis op het Netwerk, en tegenwoordig gebruiken we dat bestand niet meer (uitschakelbaar via Bedrijfsparameter Behoefterun). Je kunt de records in deze tabel opschonen door bij 6-4 de Elementaire Behoeftebasis opnieuw op te bouwen vanaf bijv. 31-12-9999. Daarna is de LOBH tabel leeg.

BBB-EURO leegmaken is op zich wel mogelijk. Meest eenvoudige manier is door bij Toevoegen Bedrijven een nieuw bedrijf toe te voegen ("LEEG"), en daarna middels "Kopieren Bestanden" Bedrijf <LEEG> naar <BBB-EURO> te kopiëren. Kopiëren Bestanden verwijdert eerst de data uit het bedrijf waarna gekopieerd moet worden, en kopieert daarna de records uit de Source <LEEG>. Resultaat is dat wel de records uit <BBB-EURO> weg zijn, en je hooguit een record bij Raadplegen Bedrijven overhoudt, die je vervolgens met F6 kunt verwijderen.

Dat klinkt ook als "liever niet doen" ...
:scratching:

Ok, dan laat ik BBB-EURO even voor wat het is.

Belangrijkste voor ons is nu dat het probleem met oa de HALGRIJ wordt opgelost.
Wat is nu de werkwijze die ik moet volgen om het in de betreffende tabellen in orde te krijgen?

Ook al gaat Wouter erover, houd het er maar op dat je dat in het algemeen niet zelf kan doen, terwijl je dat -afhankelijk van de situatie- wel zelf kan proberen (gewoon via Profit !). Maar goed, er niet vanuit gaande dat dat lukt (en pas ook op dat je het niet onbedoeld erger maakt) zal je minimaal moeten aangeven wat er naar jouw idee onjuist is, zodat Wouter het kan aanpassen.

Op zich een goede beslissing om EURO even te laten voor wat het is (je zal maar de verkeerde kant op kopiëren of zo). Maar goed, het moet natuurlijk gewoon kunnen, maar doe het dan in elk geval juist na een backup.

Ik heb een query gemaakt van LOVR (verkooporder-regels).
Hierin gezocht naar de regels die een artikel bevatten die niet als artikel in het systeem staan (zoals HAL8GRIJ) > zie kolom J.
Vervolgens de juiste artikelcode erbij gezocht middels verikaal zoeken > zie kolom K.

Het volledige bestand is naar Wouter gemaild; het gaat om 9251 verkooporderregels (van de in totaal 350000 regels, maar dat terzijde).

Morgen kijk ik naar LOLR.

En de 473 andere logistieke bestanden ?  :(

In jouw XLS kom ik een paar Verkooporderregels tegen, waarbij het Artikelnummer op die Verkooporderregel niet overeenkomt met het Artikelnummer welke jij in je XLS noemt. Hoe kan dat? Heb je \FOX\LO\LOPF\LOVR als basis gebruikt?

De overige VO regels in de Excelsheet klopten. Deze verwezen naar een niet bestaand Artikelnummer zoals opgegeven in je Excelsheet. Deze regels zijn nu gewijzigd in het nieuw opgegeven Artikelnummer.

Wouter, ik heb een nieuwe query gemaild voor LOLR.

Ja.

Is inmiddels ook gekorrigeerd.  :smile:

Heel mooi, bedankt!
Wanneer ik nog gekke dingen tegenkom post ik het hier.

Het blijkt dat een aantal artikelen nog niet goed is omgezet. Dit is echter maar een gedeelte: van de artikelen in LOVR in onderstaand schermafdruk bv alleen degene die geselecteerd is. De rest is wel goed gegaan.

Ik heb een nieuw bestand gemaild met artikelen die nog niet omgezet zijn.

Van de LOLR is alles goed gegaan op 1 na. Zie 2e schermafdruk.

Pascal, als ik jou was zou ik even uitkijken met wat je nou echt aan het doen bent. Ik vertrouw het NIET. Jou laatste Excel versie van een zelfde Verkooporder + Artikelnummer toont (feitelijk wederom) plots een andere Verkooporderregel (nu 4, eerst 3).

Wij maken -net zoals eerder- nu konversies gebaseerd op jouw informatie. Volgens mij ga ik hier zeggen ermee te stoppen ...

Je kunt in theorie 2 dingen bedoelen:

a. Jij bent een aantal VO Regels vergeten te vermelden in je Excelsheet.
b. De run heeft niet gewerkt, en heeft een aantal VO regels niet omgenummerd.

Wat mij betreft kun je alleen de 2e bedoelen. Je impliceert het door te stellen dat de rest wel goed gegaan is, maar het kán ook niet anders, immers, "als jouw Query een lijst oplevert van VO regels met Artikelnummers die niet meer bestaan", dan kun je daar niets in vergeten zijn (of je Query werkt gewoon niet).

Het eerste waarvan ik huiver is mijn eerdere opmerking: hoe is het mogelijk dat jij een Query maakt o.b.v. \FOX\LO\LOPF\LOVR en dat ik als vervolgens een extra kontrole inbouw (ja, dat schijnt niet onverstandig te zijn bij data die jij aanlevert  :wink:) die kontroleert of de Artikelnummers v/d Verkooporderregel waarnaar je verwijst wel overeenkomen met het Artikelnummer in jouw Excel, er verschillen in blijken te zitten! Dat kan niet, en dat mag niet!

Nu blijken er een aantal het niet gedaan te hebben.

Maar euh... kijk eens even naar het schermprintje...

Even los van het feit dat het absoluut niet handig is dat je e.e.a. met een andere kolomindeling aanlevert (ik heb immers een konversie moeten schrijven die de kolommen leest, die nu anders zijn), lever je eerst een Excelsheet aan waarbij het produkt op regel 3 staat, en nu op regel 4. Verklaar ???

Kan niet kloppen nee.. lijkt me idd verstandig dat ik eerst eens uitzoek wat er bij mij misgaat, voordat ik opnieuw wat aanlever.
Ik moet zodirect weg, morgenvroeg kijk ik ernaar en meld ik me wel weer.

En verder ... Verder blijkt mij nu dat je kennelijk "in staat" bent geweest om alleen al in LOVR slechts 9000 foute records door jouw kontroles te aten slippen. Dus weet je wat ? je hebt wat mij betreft NIETS gekontroleerd, en daarmee wat mij betreft ontheven van jouw "taak" om dit te doen. En het maakt me weinig uit dat ik jouw werkgever niet ben.

Als je boven terugkijkt zie je dat Wouter jou een vraag heeft gesteld aangaande inconsistenties die hij tegenkomt in jouw Excel sheets, maar een verklaring geef je niet, en zoals ik het zie zoek je die ook niet. Zoals gezegd, nu presteer je zoiets gewoon weer.

Zoek even na hoe vaak het is voorgekomen dat je een ander artikelnummer noemt dan je bedoelt, of een ander menu pad noemt dan je bedoelt. Misschien dat iemand anders jou dit doorgeeft en jij niet de "schuldige" bent in deze, maar hoe dan ook, zo gaat het niet werken in dit geval, want het is te belangrijk. Het lijkt intussen wel of wij de verantwoordelijkheid moeten hebben van jullie. Maar dat zou toch te gek zijn.

Sorry hoor, maar ik word hier niet blij van (ja, dat had je al gemerkt).
Snap het nu even ... dat foutje waar je nu mee te maken hebt (linker deel enz.) is hier in een half uur opgelost. Moeten we nu nog 2 weken besteden om je database te herstellen omdat je geen zin had om het te kontroleren alvorens het echt te doen ?? IK verdien het geld liever anders !

:dntknw:
Peter

Laat ik het zo stellen: heel profit incl alle tabellen middels textsearch volledig incl check-dubbelcheck controleren voor 1000+ omgezette artikel-id's is niet te doen in een werkweek. En ik denk ook niet in een aantal weken. Wat er allemaal niet mis kan gaan blijkt dan ook wel en ik zal ook zeker niet nogmaals zo'n actie als deze uitvoeren. Maar dit heb ik ook allang toegegeven (zie hierboven in het topic) en aangegeven dat ik het niet meer op deze manier zal doen. Plus hoe ik het een volgende keer zou doen, waarop positief is gereageerd.
Maar als aanvulling hierop: alles door 1 persoon laten controleren is, ook wanneer je nog maar enkele ipv 1000 id's wijzigt, sowieso niet verstandig. Er moeten meer mensen zijn die controles op dit soort kritische wijzigingen uitvoert.
Volgens mij ook common practise in het geval van belangrijke zaken binnen een bedrijf. Waarom dat bij de changekey niet zo is weet ik zelf eigenlijk ook niet.

Ik heb toch geantwoord dat het niet klopt en ik daar naar zal kijken? Ik las het bericht toen ik naar de beurs moest en geen tijd had om het nog weer uit te gaan zoeken en dit morgenvroeg zou oppakken. Nouja, dat is iets vroeger geworden.

Het blijkt dat beide queries juist maar niet volledig zijn: zowel regel 3 als 4 bevatten nl een BBB8GRIJ. Blijkbaar is bij het verticaal zoeken de 1e regel met BBB8GRIJ gevonden (en ook door jullie gewijzigd), maar de daaropvolgende regel (4) overgeslagen. Deze komt weer naar voren wanneer ik de query opnieuw draai, regel 4 bevat dan de 1e BBB8GRIJ die in de verkoopoorder gevonden wordt. Zie de 2 schermafdrukken: de 1e voor de aanpassingen van Wouter, de  2e na de tijd.

De querie bevatte de 2e keer minder kolommen omdat ik hem opnieuw heb aangemaakt met minder kolommen, vanwege de tijd dat het kost om de query te draaien (350.000 records). Ik dacht dat ik de minder relevante kolommen wel weg kon/mocht laten; dit is niet met opzet gedaan om jullie dwars te zitten ofzo.
Nieuwe query kan ik nu via RDP ook niet doen, want hiervoor heb ik Office 2007 nodig welke niet op de terminal server draait (doe ik morgenvroeg).