Dubbel artikel na sleutelwijziging

[pascal]

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.

[Peter Stordiau]

Ik heb een query gemaakt van LOVR (verkooporder-regels).

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?

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 ...

[Wouter Rijnbende]

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  ) 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 ???

[pascal]

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.

[Peter Stordiau]

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 !


Peter

[pascal]

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.

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.

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.

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).