[Alg] Snel zien of data gewijzigd is m.b.v. controle getal

[Polderdijk]

Ik ben bezig met het vullen van een database met gegevens uit bestanden die een vaste kolomsbreedte hebben. Elke x aantal weken krijgen we nieuwe bestanden welke dus weer moeten worden ingelezen en zonodig van Excel om moeten worden gezet naar vaste kolommen. Nu heb ik voor dat laatste een programma ontwikkeld welke dit simpel doet en waar ik een lijst kan uitprinten met daarop op elke lijn de naam van de kolom, het startplek (karakters), en de lengte van het veld. Zoals hieronder:

code:

Nr.  Start  Lengte  Naam
1   1   7   ArtikelNr
2   8   30  Omschrijving
3   38  7   Bruto
5   45  1   F5
7   46  1   Staffel
8   47  237 F8

Echter kan het voorkomen dat bijvoorbeeld de lengte van omschrijving met het volgende bestand langer is dan bij het ontwerpen van de dataport.

Nu zat ik te denken hoe ik dit simpel kan controleren, maar dat ik niet in ontwerpweergave hoeft te kijken op welke kolombreedtes deze heeft.

Wat me wel handig lijkt om een soort controle getal te maken uit bovenstaande waarden, welke dus een kort getal terug geeft welke ik in de omschrijving kan zetten van de dataport en dus snel kan zien of de velden nog gelijk zijn.

Ik heb al met een rekenmachine geprobeerd om het één en ander te verzinnen maar ik kom er echt niet uit. Is hier niet misschien een andere simpele redenering hoe ik dit kan aanpakken?

[Infinitive]

Ik zie niet in waarom je dat controle getal nodig hebt. Je kunt toch gewoon vanuit je excelsheets de import doen naar de database, dan hoef je ook niet te knoeien met vaste kolombreedten? Als dat niet mogelijk is dan zou ik zo wie zo zou ik niet voor bestanden met vaste kolombreedten gaan, maar voor comma separated o.i.d.

Of als je echt niet anders kan (?), dan de kolombreedten berekenen aan de hand van de invoerdata. Dat zou wel eens onmogelijk kunnen zijn als je kolomnamen whitespace bevatten en ook je data.

Anyway, als je toch aan het automatiseren bent, doe het dan goed en zorg ervoor dat je zelf er geen werk meer aan hebt


^^^^ ok je hebt er nog iets aan toegevoegd, zodat misschien wat van bovenstaande niet helemaal direct van toepassing is.

[ Voor 44% gewijzigd door Infinitive op 29-11-2004 14:54 ]

[Polderdijk]

Infinitive schreef op maandag 29 november 2004 @ 14:50:
Ik zie niet in waarom je dat controle getal nodig hebt. Je kunt toch gewoon vanuit je excelsheets de import doen naar de database, dan hoef je ook niet te knoeien met vaste kolombreedten? Als dat niet mogelijk is dan zou ik zo wie zo zou ik niet voor bestanden met vaste kolombreedten gaan, maar voor comma separated o.i.d.

Als dat zou kunnen is het natuurlijk fantastisch, maar ik was er even vergeten bij te vertellen dat het om Navision ging. Dit is dus een programma waar het gehele bedrijfsproces instaat, van calculatie tot verkoop. Het is eigenlijk het zelfde als een SAP of BAAN.

Het is mogelijk om een ODBC koppelijk te maken, echter moet je daar weer een optie voor kopen voor ongeveer zo'n € 8000,-. En het gaat hier om ongeveer zo'n 20 imports dus dat vinden we een beetje dure oplossing, ook gezien het feit dat er al zo'n € 200.000 is geinvesteerd erin.

[Zoijar]

Buiten het feit of je het nodig hebt of niet; je kan denk ik wel een CRC gebruiken:

google

[Infinitive]

Polderdijk schreef op maandag 29 november 2004 @ 14:53:
[...]

Als dat zou kunnen is het natuurlijk fantastisch, maar ik was er even vergeten bij te vertellen dat het om Navision ging. Dit is dus een programma waar het gehele bedrijfsproces instaat, van calculatie tot verkoop. Het is eigenlijk het zelfde als een SAP of BAAN.

Het is mogelijk om een ODBC koppelijk te maken, echter moet je daar weer een optie voor kopen voor ongeveer zo'n € 8000,-. En het gaat hier om ongeveer zo'n 20 imports dus dat vinden we een beetje dure oplossing, ook gezien het feit dat er al zo'n € 200.000 is geinvesteerd erin.

Wat voor mogelijkheden voor import heb je, want als je een import hebt om text files met vaste kolombreedten te importeren, dan kan je ongetwijfeld er ook een doen met comma separated text files?

_{Ik heb navision gezien, maar heb geen kennis van technische aspecten daarvan. Maar text import met fixed size en comma delimeted is meestal eenzelfde driver, dus ik denk dat deze er beide wel in zullen zitten.}

[ Voor 15% gewijzigd door Infinitive op 29-11-2004 14:59 ]

[Polderdijk]

Infinitive schreef op maandag 29 november 2004 @ 14:57:
[...]

Wat voor mogelijkheden voor import heb je, want als je een import hebt om text files met vaste kolombreedten te importeren, dan kan je ongetwijfeld er ook een doen met comma separated text files?

Ja dat klopt, en dat hebben we natuurlijk eerst ook gebruikt. Alleen daar zaten voor ons ook vervelende nadelen aan dat dit fout ging als er bijvoorbeeld een ; of " in de omschrijving stond. Dan wordt daar het veld al afgebroken en niet op de plek waar het moet.

Ook ging het fout op andere vreemde karakters. Ook kan Navision niet overweg met XLS bestanden maar alleen met CSV of textbestanden met vaste kolombreedte. Er is al wel gezegd dat ze met de nieuwe versie ook gebruik maken van XML maar dat is er dus nog niet.

Dus alle mogelijke andere opties hebben we al geprobeerd maar zonder succes. Alleen vaste kolombreedte is voor ons het makkelijkst en zonder fouten.

[Tomatoman]

Waarom kies je niet gewoon voor ontzettend brede kolommen van bijvoorbeeld 100 karakters per kolom? Dan kun je weer een tijdje vooruit zonder iedere keer de kolombreedtes te moeten aanpassen. Tegen de tijd dat 100 karakters per kolom te weinig is er wel een andere importoplossing (XML?) voorhanden. Het is misschien niet de elegantste oplossing, maar wel de gemakkelijkste en dus goedkoopste.