Opgelost Wat te doen met een erg lange SQL strin?

[jbusser]

Ik vraag mij het volgende af:
Als ik een behoorlijk uitgebreide SQL instructie heb waarin heel veel waarden aan variabelen worden toegekend is het dan mogelijk om zo'n string in stukjes te hakken?
Al is het alleen maar voor de leesbaarheid.
Ik heb nu een SQL-instructie als deze:

SqlString = "INSERT INTO tbl_Vooraad (Veld1, Veld2,...etc) SELECT Waarde1, Waarde2,...etc FROM tbl_Produkten WHERE opnemen > 0;"
DoCmd.RunSQL SqlString

Deze loopt prima en is ook nog wel te overzien maar in de praktijk heeft deze al zo'n 10 velden die gevuld moeten worden en ik voorzie voor de toekomst dat er nog veel meer velden "over" moeten.

 

[Aar]

Als je al velden gaat nummeren, dan moet je toch even naar je database-model gaan kijken, want dan ben je al verkeerd bezig.
Lees ook eens deze uitleg:

Beschrijving van de databasenormalisatie - Microsoft 365 Apps

Beschrijft de manier waarop de database genormaliseerd kan worden en geef enkele alternatieven om de vormen te normaliseren. U moet de databaseprincipes weten om ze te begrijpen of u kunt de stappen volgen die in het artikel worden vermeld.

learn.microsoft.com

Of gaat het om velden die los van elkaar staan en die elkaar niet opvolgen?

 

[xps351]

Je kan de string verdelen over meer regels om hem overzichtelijker te maken. Bijvoorbeeld:

SqlString = "INSERT INTO tbl_Vooraad (" & _
                "Veld1, " & _
                "Veld2, " & _ etc...........

Maar ik heb geen goed gevoel bij het idee dat je zoveel velden kopieert van de ene tabel naar de andere. Ook een tabel voorraad is "verdacht" (want af te leiden uit voorraadmutaties).

 

[jbusser]

@Aar:
Ik gebruik natuurlijk geen namen als veld1, veld2 etc. maar dit was een "bijvoorbeeldje" omdat de werkelijke veldnamen niets toevoegen aan de eigenlijke vraag.
@ Peter
Tja, dat kan ook natuurlijk!
Overigens gaat het om een aantal product-specifieke kenmerken die wekelijks gecontroleerd moeten worden en die vastgelegd zijn in de tabel tbl_Producten (= product + kenmerken)
In een werklijst, die dus wekelijks wordt aangemaakt, moeten een flink aantal van die specifieke kenmerken gecontroleerd worden. Probleem is echter: dit hoeft lang niet bij alle producten, dus is er een selectie van producten waarvan een werklijst gemaakt moet worden...
Lastig uit te leggen, maar erg moeilijk is het niet.
Ik vroeg gewoon om jouw antwoord, waarvoor dank!

 

[OctaFish]

Ik vind je WHERE parameter bijzonder gevaarlijk; als je deze query (per ongeluk) twee keer uitvoert, heb je alle waarden er twee keer inzitten. Ik zou op zijn minst een check inbouwen die dat ondervangt.

 

[jbusser]

Ik heb daarvoor ook een check ingebouwd.
De "WHERE opnemen > 0;"-parameter is zo gemaakt omdat de items die naar in werklijst moeten worden gekopieerd op een bepaalde volgorde op die lijst moeten komen. Tevens is deze lijst zeer variabel en zo kunnen medewerkers zelf het wel (>0) of niet (0) opnemen op de werklijst en daarmee ook aangeven op welke volgorde (het formulier wordt immers op "opnemen" gesorteerd!
Maar... Bedankt!