[VB6/Access] Discussie: Werken met meerdere identieke tables

[RaZ]

Ik wil het nu wel eens weten. Wie is er dom bezig, ik of m'n collega?

Er is met VB6 een applicatie gemaakt, om adressen te bewerken. De addressen komen in doormiddel van dit stukkie software altijd in het zelfde formaat eruit te zien.

Voorbeeld van de tables:
• Bedrijf1
• Bedrijf2
• Bedrijf3
• Kontakpersoon
• Adres
• Postcode
• Plaats

In eerste instantie hadden we 1 table, Import in VB een connectie: DIP

Als bedrijf 2 of 3 niet was gevuld, zou je op een etiket lege regels krijgen, de we verplaatsen de inhoud van wat velden, zodat alles netjes onder elkaar wordt geprint. Deze functies moest je handmatig starten.

Doordat we niet helemaal tevreden waren met de output hiervan, omdat het nog gesorteerd moest worden.

(Alles lag doorelkaar, zoals de klant het bestand aanleverd)

Ok, we maken een sorteer-sleutel, leggen Import op volgorde, en janken dan de hele handel over, op die volgorde, naar een andere table, Export (in VB een connectie: DUP

Na het sorteren kwam je er wel eens achter, shit, vergeten die velden onderelkaar te zetten. Dus ik stel voor, die functie moet ook werken met de table Export.

De functie die dus dat aansluiten van de velden deed voor DIP, heet: Inschuiven
Hij called die functies met:
Call Inschuiven(DIP)

de functies Inschuiven is gemaakt, en ziet er uit:
Sub Inschuiven(DIP)
[niet van toepassing]
End Sub

Wat doet meneer: maakt een 2de functies: Inschuiven_DUP

Lekker omslachtig lijkt me zo, want je kan ook, aangezien de tables identiek zijn, ook de connectie meesturen naar een functie, en die in een var hangen:
Voorbeeld: Oh, je wilt velden inschuiven? ding weet of er gesorteerd is of niet, is dit niet het geval, dan doe je:
Call Inschuiven(DIP)
zit je data als in Export, dan call je:
Call Inschijven(DUP)

Dan ziet je functie er uit volgensmij:
Function Inschuiven(TOET)
TOET.Recordset.MoveFirst
etc..
End Function

Nu gebruiken we 3 tables, en voor alles worden 3 functies geschreven. Stel nu, er moest een kleine aanpassing komen, moet je wel alle functies herschrijven.

Hij houd voet bij stuk dat zijn code overzichtelijk werkt, omdat als er een bug is, er dan achter te komen is, met welke table het fout gaat.

Ik zeg op mijn beurt: dan stuur je een variable mee met het callen van je functie, waar je vermeld, met welke table je bezig bent.

Kortom... Wie is er omslachtig aan't programeren?

NB: hij zegt dit werk al 20 jaar te doen, ik 6 maanden

[T-MOB]

Misschien ben ik gek, maar twee tabellen met exact dezelfde data is toch zowieso kolder?? ACCES kan toch wel gesorteerd data uit zo'n tabel halen. * T-MOB snapt het nut van de export tabel niet.

Daarnaast lijkt het mij ook handiger om 1 functie te gebruiken voor dezelfde funcionaliteit. Anders kun je net zo goed géén functie maken. Dan kun je precies zien waar je een typo hebt gemaakt bij het uitschrijven van al die code...

[Verwijderd]

Ik krijg sowieso een beetje de griebel van jullie werkwijze. Meer dan 1 tabel is niet nodig, want een database is goed in sorteren, en je kunt de data manipuleren in code zoals je wil. Misschien is er een reden die ik niet zie, maar goed.

In mijn bescheiden mening kan je er beter 1 funktie op na houden, tenzij er echt heel verschillende dingen gebeuren. Duplicatie van code is nooit een goed idee en veroorzaakt juist bugs.

[RaZ]

Ok, misschien ben ik vergeten te zeggen: De bewerkte adressen, die dus uiteindelijk in de Export-table zit, gaan we met een 3rd Party printen.

Dit programma kan alleen maar Access-Tables aan, met een volgorde waarop ze zijn aangemaakt.

Dat je een sorteren binnen Access kan maken, is bekend. Wat er gebeurd is, Table Import wordt op een volgorde gelegd, en op die volgorde wordt deze record voor record naar de Export table gegooit, anders hebben we er niets aan.

Daarom is er gekozen om de table Import op een sorteer-slag te zetten, bijvoorbeeld postcodes: 1000 AA - 9999 ZZ, en dan moet er dus een nieuwe table worden gevuld, anders snapt het programma waarmee we printen het niet.

[Verwijderd]

Je kunt van de export tabel toch ook een query maken ? Het moet voor je externe programma niet uitmaken of het een echte tabel of een query is.

Verder neem je aan dat Access de data retourneert in de volgorde waarin het in de tabel is gezet. Al lijkt dit te werken, mag je dit NOOIT aannemen. Een relationele database heeft geen inherente sortering, ook niet op volgorde van invoer.

[RaZ]

Verwijderd schreef op 18 oktober 2004 @ 21:29:
Je kunt van de export tabel toch ook een query maken ? Het moet voor je externe programma niet uitmaken of het een echte tabel of een query is.

Verder neem je aan dat Access de data retourneert in de volgorde waarin het in de tabel is gezet. Al lijkt dit te werken, mag je dit NOOIT aannemen. Een relationele database heeft geen inherente sortering, ook niet op volgorde van invoer.

Juist.
Net een paar testjes gedaan.

In access de table Import gesorteerd op naam, en het opnieuw een record-nummer laten maken.
In de query alle velden gepakt, en op volgorde van record-nummer.

Werkt

Ook de table Import op postcode gesorteerd, en weer het record-nummer opnieuw aangemaakt, en WEER alles op de juiste volgorde.

Het ziet er dus naar uit, dat die hele Export table totaal niet nodig meer is, het sorteren van grote bestand was namelijk nogal een tijdrovende bewerking.

Met de Visual Data Manager maakte we sorteer-sleutels, en legde ze Import goed, en vervolgens leegde we Export, en schreven vanaf Import alles record-voor-record weg de Export in. Nu is het gewoon een kwestie van, het veld record-nummer hernummeren. En de query pakken.

Da's sowieso een flinke snelheids winst. Muchoos Gracias

Nog een test gedaan: Als we zaten met adressen waar meerdere bijzaten (dus een etiket voor 2 of meerdere items) gooide we die altijd naar een nog een andere tabel: Meedere Zelfs dat is met een query dus ook af te vangen. Ik heb nooit geweten dat dit ook kon. Enige ervaring die ik had was het lezen van de source van die collega die dus niet de Access-Guru blijkt te zijn dat hij zegt dat'ie is

Hij's nu op vakantie, ik zal dat ding van de week eens flink onder handen nemen, en hij weet niet wat ie ziet maandag

[ Voor 17% gewijzigd door RaZ op 18-10-2004 22:24 ]

[Verwijderd]

nog 1 ding : Waarom de extra stap van het omnummeren ? je kunt toch in de query gelijk sorteren op het veld dat je wilt hebben ?