[VBA] Niet-geïntialiseerde variabele in 64 bit office

[Maasluip]

Ik heb een stukje code in MS Access VBA dat een aantal variabelen in een zelf-gedefinieerde type vult en die naar een recordset overzet om in een tabel te inserten.
Werkte allemaal perfect met de laatste 32 bits Office versie, de 64 bits Office versie crasht.

Wat blijkt het probleem: een van de variabelen vul ik niet. Die is dan met een lege string gevuld. Als ik die aan de recordset toeken dan crasht Access.
Maar als ik die variabele specifiek met een lege string vul, dan gaat het wel goed.

code:

Type DELIV_HEAD_type
    ID  As LongLong
    Delivery_ref    As String
    cust_nr          As String
    Country         As String
    Ship_type       As String
    Destination     As String
    Order_ref       As String
    Status          As String
End Type

Dim dh As DELIV_HEAD_type

dh.Delivery_ref = Trim(Mid(sLine, 1, 8))
dh.cust_nr = Trim(Mid(sLine, 12, 10))
dh.Country = Trim(Mid(sLine, 23, 4))
dh.Ship_type = Trim(Mid(sLine, 28, 4))
dh.Destination = Trim(Mid(sLine, 33, 50))
'dh.Status = ""

    Set rs = New ADODB.Recordset
    rs.Open "DELIV_HEAD", CurrentProject.Connection, adOpenDynamic, adLockPessimistic, adCmdTable
    With rs
        .AddNew
        .Fields("Delivery_ref") = dh.Delivery_ref
        .Fields("cust_nr") = dh.cust_nr
        .Fields("Country") = dh.Country
        .Fields("Ship_type") = dh.Ship_type
        .Fields("Destination") = dh.Destination
        .Fields("Status") = dh.Status
        .Update
    End With

Dit gaat fout, met een crash op .Fields("Status") = dh.Status.
dh.Status is gevuld met "" (een lege string).
Als ik de comment bij 'dh.Status = "" weghaal en die dus expliciet met een lege string vul gaat het goed.

Iemand bekend met dit gedrag? Moet je nu in 64 bits VBA altijd alle variabelen specifiek vullen voordat je ze aan een recordset toekent?

[RobIII]

Maasluip schreef op donderdag 3 oktober 2019 @ 15:35:
Moet je nu in 64 bits VBA altijd alle variabelen specifiek vullen voordat je ze aan een recordset toekent?

Laat ik even een tegenvraag stellen: so what if you do have to? Variabelen initialiseren is sowieso een goed idee.

[Joep]

Wat @RobIII zegt. Access heeft zo z'n quirks, zeker de 64-bits versie. Misschien lukt het op een andere manier wel? CurrentDb.Execute "SQL string hier" al geprobeerd bijvoorbeeld?

Edit: SQL is niet het antwoord hier

[ Voor 12% gewijzigd door Joep op 03-10-2019 16:24 ]

[Maasluip]

RobIII schreef op donderdag 3 oktober 2019 @ 15:52:
[...]

Laat ik even een tegenvraag stellen: so what if you do have to? Variabelen initialiseren is sowieso een goed idee.

Dat was altijd het voordeel van VB, variabelen worden impliciet geïnitialiseerd.

Maar het is wel handig om te weten of dit een of andere bug is of dat ik al onze databases moet nagaan hoe er met variabelen wordt omgegaan.
Dus als het moet, dan is dat nogal wat werk. Als het een setting is dan zou dat ook helpen.

[Gomez12]

Hoe kom je erbij dat dh.Status gevuld zou zijn met een lege string? dh.Status zou ik gewoon als null waarde verwachten.

En daarom ook mijn 2e vraag, definieer "Access Crashed", heb je fatsoenlijke foutafhandeling en wat zegt die of heb je geen foutafhandeling en mag Access gewoon maar wat doen als hij de mist ingaat en ervaar je dit als crashen?

Want puur qua gok zou ik zeggen dat je dbase veld Status simpelweg non-nullable is, waardoor je er geen null in mag opslaan maar wel een lege string.

[Joep]

@Gomez12 Dan zou Access ook met een foutmelding moeten komen in de 32-bit versie.

Edit: Een niet geïnitialiseerde string hoort een lege string te bevatten (in Access tenminste ). Testje in laatste versie van Access 64 bit:



Edit 2: Dit is hoe ik het altijd in DAO doe en dat werkt gewoon zoals verwacht in de laatste versie van Access 64-bit. Er wordt gewoon een record toegevoegd, waarbij veld Poep gewoon een lege string bevat, zelfs als ik een default value toevoeg aan veld Poep.

Visual Basic:

Sub Derp()
    Dim strNaam As String
    Dim strPoep As String
    
    strNaam = "Bla"
    
    Dim rsRecordset As DAO.Recordset
    Set rsRecordset = CurrentDb.OpenRecordset("tblTest", dbOpenDynaset, dbSeeChanges)
    
    rsRecordset.AddNew
    rsRecordset!Naam = strNaam
    rsRecordset!Poep = strPoep
    rsRecordset.Update
End Sub

[ Voor 109% gewijzigd door Joep op 03-10-2019 22:55 ]

[farlane]

Joep schreef op donderdag 3 oktober 2019 @ 22:13:
@Gomez12 Dan zou Access ook met een foutmelding moeten komen in de 32-bit versie.

Maar wat is dan de specifieke exception die optreedt? Of crashed heel office als je dit doet?

Dit is hoe ik het altijd in DAO doe en dat werkt gewoon zoals verwacht in de laatste versie van Access

Ik dacht dat DAO honderd jaar geleden al legacy was, maar blijkbaar wil het nog niet sterven ...

[Joep]

farlane schreef op vrijdag 4 oktober 2019 @ 08:10:
Ik dacht dat DAO honderd jaar geleden al legacy was, maar blijkbaar wil het nog niet sterven ...

Alsjeblieft: http://www.utteraccess.co..._DAO_and_ADO#Pros_vs_Cons

[farlane]

Joep schreef op vrijdag 4 oktober 2019 @ 08:45:
Alsjeblieft: http://www.utteraccess.co..._DAO_and_ADO#Pros_vs_Cons

Dankjewel, maar ik ga er van uit dat ik Access niet meer ga gebruiken.

[Joep]

Daar heb ik alle begrip voor

[Maasluip]

farlane schreef op vrijdag 4 oktober 2019 @ 08:10:
[...]

Maar wat is dan de specifieke exception die optreedt? Of crashed heel office als je dit doet?

Geen exception, heel office crasht. Dit zijn de meldingen:



En als ik daar op debug druk heb ik helaas geen debugger. Ik kan hem ook niet enabelen want die optie heb ik niet.


Daarna is MS Access weg.

Testje van @Joep :

Niet vullen van de waarde:

code:

?dh.Status

?"A" & dh.Status & "A"
AA
?isnull(dh.Status)
False
?vbNullstring=dh.Status
True

Wel vullen met dh.Status = "":

code:

?dh.Status

?"A" & dh.Status & "A"
AA
?isnull(dh.Status)
False
?vbNullstring=dh.Status
True

Voor de gebruiker dus exact hetzelfde. Voor het systeem niet.
Als ik rs!Status = dh.Status doe i.p.v. in plaats van rs.Fields("Status") = dh.Status heb ik hetzelfde resultaat: crash.

[ Voor 27% gewijzigd door Maasluip op 07-10-2019 10:36 ]

[Joep]

Klinkt als een feature bug
Niks aan te doen lijkt me, behalve er in het vervolg rekening mee te houden zoals RobIII al zei. Je kunt de bug wel melden bij Microsoft, maar ik acht de kans zeer klein dat er iets aan gedaan zal worden.

[DynaSpan]

Ik werk hier ook nog af en toe met oude VBA meuk, het debuggen is vaak wel makkelijker door er een (VB) try-catch omheen te gooien en dan de error in een MessageBox te printen.

[RobIII]

DynaSpan schreef op maandag 7 oktober 2019 @ 14:38:
Ik werk hier ook nog af en toe met oude VBA meuk, het debuggen is vaak wel makkelijker door er een (VB) try-catch omheen te gooien en dan de error in een MessageBox te printen.

Ik kan me vergissen maar VBA ondersteunt toch geen try-catch? Alleen "On Error ..."
En gezien de crash ga ik er van uit dat een evt. errorhandling of catch nooit aangeroepen gaat worden.

[ Voor 12% gewijzigd door RobIII op 07-10-2019 14:45 ]

[DynaSpan]

Ik heb wel eens geluk gehad met dit soort stukjes code:

code:

On Error GoTo ErrHandler
.......
.......
.......
ErrHandler:

    'handle the error
    If Err.Number <> 0 Then

        'the error handler is now active
        Debug.Print (Err.Description)

    End If

    'disable previous error handler (VERY IMPORTANT)
    On Error GoTo 0
    'exit the error handler
    Resume Next

Waarna je in de if de error # kon vinden en kon Googlen. Geen idee of ze in dit specifieke geval aangeroepen worden, bij mijn VBA-meuk werkte het wel voor de meeste dingen.

[ Voor 33% gewijzigd door DynaSpan op 07-10-2019 15:38 ]

[Gomez12]

Maasluip schreef op maandag 7 oktober 2019 @ 10:25:
[...]
Voor de gebruiker dus exact hetzelfde. Voor het systeem niet.
Als ik rs!Status = dh.Status doe i.p.v. in plaats van rs.Fields("Status") = dh.Status heb ik hetzelfde resultaat: crash.

Is je recordset wel access? Of iets anders?

Want in onderstaand stukje zeg je in wezen neits :

Set rs = New ADODB.Recordset
rs.Open "DELIV_HEAD", CurrentProject.Connection,

Behalve dat je een adodb recordset wilt van currentproject.connection, maar currentproject.connection kan net zo goed een oracle database zijn als je dat zo gedefinieerd hebt in je currentproject...

[farlane]

Vind het wel een interessant probleem eigenlijk. Laat ik stellen dat het probleem niet kan zitten in de code die je hier laat zien, daarvoor is het te simpel.

Wat ik me wel afvraag:
- Wat is het resultaat als je iets dergelijks doet met een andere (string) veld/kolom?
- Wat is de definitie van de kolom in Access. Wat zijn de verschillen mocht het met een andere kolom wel goed werken?

[Maasluip]

Gomez12 schreef op maandag 7 oktober 2019 @ 16:52:
[...]

Is je recordset wel access? Of iets anders?

Want in onderstaand stukje zeg je in wezen neits :

[...]

Behalve dat je een adodb recordset wilt van currentproject.connection, maar currentproject.connection kan net zo goed een oracle database zijn als je dat zo gedefinieerd hebt in je currentproject...

Ja, het is de database waar het stukje VBA in zit. Access accdb. CurrentProject wordt nergens geherdefinieerd.

[Gomez12]

Tja, dan zou ik zeggen maak een klein mini stukje vba wat exact dit opwekt zodat Joep het kan testen om te zien of het echt altijd fout gaat in Access 64. Of alleen bij jullie installaties (/versies van dll's bijv)

Joep lijkt vooralsnog de enige te zijn die ook Access 64 heeft.

[Joep]

Tegenwoordig wordt van Access (via O365 i.i.g.) altijd de 64-bit-versie geïnstalleerd, tenzij je anders aangeeft tijdens de installatie.