Update veld van een tabel. DoCmd.RunSQL

Als je met twee variabelen werkt, krijg je zoiets:
Heb het getest in een eigen db, en dit werkt prima.

Dank. Als ik de strSQL uitvoer, blijkt dat het ID nummer niet wordt ingevuld. Dit is het resultaat als ik Debug.Print strSQL doe voordat de regel CurrentDb.Execute strSQL, dbFailOnError wordt uitgevoerd < UPDATE Bijlagen set [Bijlage3] = "20201-19___BriefX.docx", [] = "D:\Bijlagen_email_db\Vervangen\T schijf" WHERE Bijlagen_ID = >. Na docx, zie ik twee haakjes [], waarvoor zijn die en waarom wordt het ID nummer niet bij Bijlagen_ID ingevuld? De velden worden in de tabel ook niet geupdated.

Het volgende valt op. de strSQL code wert echter als ik een reeds bestaand formulier met een bekend ID gebruik (record staat reeds tussen de andere records in de tabel) om de bijlagen op te slaan, dan gaat het goed en is het Bijlagen_ID=12. Als een nieuwe record onder aan de tabel wordt aangemaakt met een nieuwe ID verwijzing naar het formulier, dan gaat het fout en ontbreekt in Bijlage_ID= het nummer. De record is wel met het goed ID nummer aangemaakt maar de bijlagen worden niet opgeslagen.

Ik heb je veldnaam tussen twee haken gezet, voor het geval er spaties in de veldnaam zitten. Daar loopt de code dan op stuk. Als er niks tussen staat, wordt de variabele dus niet gevuld.

antwoord op:

Syntaxfout (operator ontbreekt) in query-expressie [Bijlagen_ID]=. Wat zou het kunnen zijn?

Klik om te vergroten...

ik die een typfout heb gemaakt en een & ben vergeten

Jij, evenals Noellag en edMoor, zijn er altijd om per omgaande advies te geven, top. Het wordt erg gewaardeerd. Ik ben nog wel benieuwd waar die & moet komen te staan.
De ID kwestie is volgens mij dat de Bijlagen_ID niet in de Recordbron is meegegeven. Ik heb het opgelost met een TempVar add en de Bijlagen_ID vanuit een ander formulier. De ID kan dus nu niet meer veranderen.
In eerste instantie lijkt te werken maar nu wordt de eerste van de bijlagen van de drie niet opgeslagen in de tabel en soms de eerste en de derde, de tweede weer wel.
Is BijlagePad1 als veldnaam correct?
Omdat ik via een andere weg het ID nummer (IDnr) heb bepaald, heb ik de coderegel aangepast. Is deze correct aangepast? Morgen verder testen. Dank.

Ter aanvulling op vraag #25. Als 3 bijlagen worden toegevoegd aan een reeds bestaand record, dan gaat de opslag in de tabelvelden goed en wordt het formulier Me.Form.Requery gerefreshed en worden de bijlagen in het formulier getoond. Als de bijlagen in een nieuw record moeten worden opgeslagen, dan gaat het fout. De padnaam BijlagePad1 wordt geupdated. Het eerste veld en soms het laatste veld worden niet geupdated en blijven leeg. Daarbij wordt het formulier niet gerefreshed. De code CurrentDb.Execute strSQL, en Me.Form.Requery worden zonder foutmelding doorlopen (zie ook vraag #17). De SQL strings (strSQL) zien er nmi. foutloos uit.
Waarom worden de bijlagen c.q. de velden Bijlage1, Bijlage2 en Bijlage3 niet geupdated?

Ik zou je bijlagen sowieso niet via deze constructie opslaan; deze tabel is niet genormaliseerd en vroeg of laat ga je dus in de problemen komen (anders dan nu ). Gebruik een gekoppelde tabel voor je bijlagen met één bijlage veld, en een koppeling met je brontabel. Is vele malen flexibeler en je bent van je probleem af. Gewoon met een lus dus alle bijlagen toevoegen aan nieuwe records.

Het is een gekoppelde tabel met alleen bijlagen. Iedere record kan 26 bijlagen en het BijlagenPad1 bevatten.
Iedere record is gerelateerd aan een uniek werkformulier. In een lus worden maximaal 26 bijlagen toegevoegd. Waarom kun je in de tabel in een bestaande record wel velden updaten en als het een nieuw record is, soms niet. Soms heeft de gebruiker handmatig een bijlage toegevoegd en is er dus een record aangemaakt waar je daarna nog andere bijlagen automatisch uit de email wilt toevoegen. Dat gaat goed maar met een nieuw record niet.

Tevens wordt de Me.Form.Requery op een bestaande record wel en bij een nieuw record niet uitgevoerd. Als ik het formulier sluit en weer open, zie je wel de gegevens van de tabel staan. Ik kan beslist de structuur niet meer veranderen in een bestaande omgeving.
Je had het nog over een & die er niet was (item 13 juni 21.37 uur).

KPTPTT zei:

Het is een gekoppelde tabel met alleen bijlagen. Iedere record kan 26 bijlagen en het BijlagenPad1 bevatten.

Klik om te vergroten...

Oh man, ben ik blij dat ik goed op mijn stoel zit! Dit is zo'n beetje de slechts genormaliseerde tabel die ik in jaren heb gezien! Nogmaals: één bijlageveld is meer dan voldoende, en voor elke bijlage maak je een apart record. Ben je óók niet aan het 'maximum' van 26 gebonden. Alhoewel: ik zie je er wel voor aan om er dan gewoon 10 velden bij te pleuren .

Jammer, dat het een schok is, excuses. De bijlagen draait inmiddels drie jaar met succes en zonder problemen. Met de jaren word ik ook wijzer maar ik kan nu nier meer terug. Het is een leerproces, zoals voor iedereen. Als de tabel en de code niet te redden is, moet ik er maar mee stoppen om mijn wens uit te voeren. Jammer want de uitgebreide code voor de bijlagen die ik nu geschreven hebt werkt, doch alleen de opslag van de strSQL van een nieuwe record in de tabel hapert. Bestaande records gaan goed. Het lijkt mij vreemd dat je geen update van een tabel op betrouwbare wijze kan doen omdat er nu meer velden in een record zitten. De meeste tabellen beschikken toch over meerdere velden.

KPTPTT zei:

De bijlagen draait inmiddels drie jaar met succes en zonder problemen. Met de jaren word ik ook wijzer maar ik kan nu nier meer terug.

Klik om te vergroten...

Dat is niet waar; in deze situatie kun je best een verbetering aanbrengen. Kost zelfs niet meer dan een uurtje, schat ik. Tenzij je heel veel meer doet met die tabel. Toch jammer dat je die stap niet kan/wil maken .

Ik ga toch niet in een bedrijfssituatie waar men met 3 man dag in dag uit met de app werkt en inmiddels voor dit jaar al ca. 10.000 bijlagen in een tabel zijn opgeslagen de structuur niet veranderen. Dit risico neem ik niet. Misschien voor volgende jaar. Ieder jaar een schone database.
Ik heb inmiddels twee oplossingen doorgevoerd en die lijken mogelijk te werken. Moet nog verder gaan testen. Het heeft dagen met veel inspanning en volhardendheid gekost maar dan heb je wat, alleen niet voor iedereen.

KPTPTT zei:

Het heeft dagen met veel inspanning en volhardendheid gekost maar dan heb je wat, alleen niet voor iedereen.

Klik om te vergroten...

Kijk, dat is nu nét waar bedrijfsprocessen op stuk lopen, of uit de kosten gieren. Doormodderen op een verkeerde weg kan weliswaar best tijdelijk soelaas bieden, maar uiteindelijk kost het je veel meer tijd/geld dan even een stap terug doen, het proces tegen het licht houden en overnieuw starten. Uiteindelijk ben je dan beter uit. Elk jaar een nieuwe db lijkt mij overigens ook een concept waar je niet gelukkiger van wordt . Beschouw het als een stevig leermomentje .

Laten we svp deze discussie ophouden. Soms hebben mensen andere ideeën, doen soms heel verkeerde dingen. Het maakt mij voorzichtig met vraagstellen en vooral daarbij te laten blijken hoe mijn oplossing is. Ik had graag antwoord gehad op de vraag van &, tips om de bestanden in de tabel op te kunnen slaan en de refresh van het formulier. Maar ik heb het inmiddels opgelost.

Je moet uiteraard vooral vragen blijven stellen, maar daarbij moet je niet vreemd opkijken als mensen (in ieder geval ik) je tips blijven geven hoe je het écht zou moeten oplossen. Lapoplossingen kunnen nooit het doel zijn van een forum, of van goede help. Die is er, wat mij betreft, op gericht om je daadwerkelijk met correcte oplossingen naar huis te sturen. Noodverbandjes laat ik graag aan anderen over .