[VB.Net] Fehler beim Schreiben in Access 07 Datenbank

SonMarcel

Mitglied
Hallo zusammen,

ich versuche vergeblich eine Access 2007 Tabelle mit Daten zu befüllen, nur erhalte ich jedes mal eine Fehlermeldung. Zunächst der SQL-Befehl, den ich von Visual Basic übergeben lasse:

Code:
cmd.CommandText = "insert into Adressklärung " & _
                                "(Paketnummer, Paketstatus, Urlaub_bis, " & _
                                "FirmaPKS, NamePKS, StraßePKS, PLZPKS, OrtPKS, " & _
                                "TelefonPKS, Ausweichanschrift, " & _
                                "FirmaAusweich, NameAusweich, StraßeAusweich, " & _
                                "PLZAusweich, OrtAusweich, TelefonAusweich, " & _
                                "Besonderheiten_1, Besonderheiten_2, " & _
                                "Zustelltermin_neu, Speicherdatum, Bearbeiter) " & _
                                "values (" & _
                                CLng(Val(txtPaketnummer.Text)) & ", " & _
                                CByte(cmbStatus.SelectedIndex) & ", '" & _
                                CDate(dtUrlaub_bis) & "', '" & _
                                CStr(txtFirma.Text) & "', '" & _
                                CStr(txtName.Text) & "', '" & _
                                CStr(txtStraße.Text) & "', " & _
                                CInt((Val(txtPLZ.Text))) & ", '" & _
                                CStr(txtOrt.Text) & "', '" & _
                                CStr(txtTelefon.Text) & "', " & _
                                CBool(optNein.Checked) & ", '" & _
                                CStr(txtFirmaA.Text) & "', '" & _
                                CStr(txtNameA.Text) & "', '" & _
                                CStr(txtStraßeA.Text) & "', " & _
                                CInt((Val(txtPLZA.Text))) & ", '" & _
                                CStr(txtOrtA.Text) & "', '" & _
                                CStr(txtTelefonA.Text) & "', '" & _
                                CStr(txtBesonderheiten1.Text) & "', '" & _
                                CStr(txtBesonderheiten2.Text) & "', '" & _
                                CDate(dtZustelltermin_neu) & "', '" & _
                                CDate(dtSpeicherdatum) & "', '" & _
                                CStr(strBearbeiter) & "')"


Die Fehlermeldung, die bei diesem Befehl erscheint lautet "Datentypen in Kriterienausdruck unverträglich". Ich vermute stark, dass dies mit der Paketnummer zusammenhängt.
Diese ist eine 14-stellige Zahlenfolge, daher konvertiere ich diese als Long. Im Access 2007 habe ich als Typ "Zahl" und "Long Integer" ausgewählt, damit sollte der Typ ja eigentlich in Ordnung sein!

Mache ich nun aus

Code:
CLng(Val(txtPaketnummer.Text)) & ", " & _

den Befehl

Code:
CStr(txtPaketnummer.Text) & ", " & _

und stelle im Access den Felddatentyp um auf Text, erscheint folgende, vielsagende Fehlermeldung: "Überlauf". Nun, da sich die Fehlermeldung bei Änderung dieser einen Zeile auch ändert, würde ich
den Fehler spontan darin vermuten.

Kann mir vielleicht einer weiterhelfen? Ich verstehe wirklich nicht, was die Datenbank gegen meinen Befehl hat...

Danke schon einmal im Vorraus!

Gruß,

sonmarcel
 
Man verwendet vernünftigerweise auch weder Access noch VB :D

Aber im Ernst: Weil du dein Kommando als Text übergibst, kannst du auch einfach deine Textvariable für die Nummer als Text anhängen; eine Konvertierung in eine Zahl ist redundant, weil der &-Operator zur Textvereinigung deine Zahl auch wieder in Text umwandelt. Es reicht aus, dass du deinen Text nicht in Hochkommas setzt, die Val-Funktion brauchst du nicht.. Deine Fehlermeldung Überlauf kommt wahrscheinlich daher, dass die Zahl für die Val-Funktion zu groß ist.
Den größten Teil deiner Konvertierungs-Aufrufe kannst du wahrscheinlich weglassen, z.B. CStr.
 
Man verwendet vernünftigerweise auch weder Access noch VB :D

Ach, lass mir doch den Spaß, ich will eben klein und kompliziert anfangen :D

Aber im Ernst: Weil du dein Kommando als Text übergibst, kannst du auch einfach deine Textvariable für die Nummer als Text anhängen; eine Konvertierung in eine Zahl ist redundant, weil der &-Operator zur Textvereinigung deine Zahl auch wieder in Text umwandelt. Es reicht aus, dass du deinen Text nicht in Hochkommas setzt, die Val-Funktion brauchst du nicht..

Ich verwende die Val-Funktion nur deshalb, damit Buchstaben, die der Benutzer fälschlicherweise eingibt, entfernt werden. Die Hochkommatas scheinen erforderlich zu sein, da eine Eingabe des Namens wie "Mustermann, Max" die Syntax dureinanderhauen würden. Oder?

Den größten Teil deiner Konvertierungs-Aufrufe kannst du wahrscheinlich weglassen, z.B. CStr.
Ich habe "Option Strict" aktiviert, daher die explizite Konvertierung. Lohnt sich dies überhaupt, oder ist es letztenendes doch mehr Arbeit?

Deine Fehlermeldung Überlauf kommt wahrscheinlich daher, dass die Zahl für die Val-Funktion zu groß ist.


Ich habe doch in der Tat die Lösung gefunden! In VB .Net ist der Wertebereich eines Integers von -2,1 Mrd bis +2,1 Mrd, bei Access ist der Wertebereich eines Integers jedoch = dem eines Shorts in VB .Net, also -32.768 bis +32.768. Nach einem Ändern im Accress in Long Integer funktioniert das Schreiben nun erfolgreich.
Ist es heutzutage eigentlich noch wichtig, genau auf die Datentypen zu achten, oder kann man bedenkenlos Longs, Decimals und Strings verwenden? In dem VB .Net-Tutorial von diesem Forum war nämlich davon die Rede, dass man zur Sicherheit vor logischen oder mathematischen Fehlern lieber den Wertebereich einschränken sollte.

Was fällt Microsoft eigentlich ein, die Wertebereiche vom Integer in den beiden Programmen verschieden zu definieren?
 
Ach, lass mir doch den Spaß, ich will eben klein und kompliziert anfangen :D
Der Spaß sei dir gegönnt :D
Ich verwende die Val-Funktion nur deshalb, damit Buchstaben, die der Benutzer fälschlicherweise eingibt, entfernt werden. Die Hochkommatas scheinen erforderlich zu sein, da eine Eingabe des Namens wie "Mustermann, Max" die Syntax dureinanderhauen würden. Oder?
Gegen die Hochkommas bei Text sage ich auch nichts, ich meinte die bei Zahlen, aber die verwendest du sowieso nicht. Allerdings splittet man den Namen normalerweise in Nachname und Vorname auf (erste Normalform, siehe Normalisierung). Die Wahrung der syntaktischen Validierung, d.h. das Verhindern ungültiger Eingaben, ist eigentlich Aufgabe des Eingabeformulars bzw. (beispielsweise bei Dateien) der jeweiligen Einlesefunktion; die Speicherroutine der Datenbank sollte damit nicht belastet werden.
Ich habe "Option Strict" aktiviert, daher die explizite Konvertierung. Lohnt sich dies überhaupt, oder ist es letztenendes doch mehr Arbeit?
Die 'Option Strict' kann bei der Erstellung von Programmen dazu motivieren, die Datentypen genauer aufeinander abzustimmen (was durchaus zu empfehlen ist), aber alle Fehlerquellen können dadurch nicht verhindert werden (wie du gemerkt hast). Allerdings verhindert sie auch eine 'späte Bindung', weswegen sie in manchen Programmen nicht anwendbar ist. Bei sauberer Planung ist sie nicht notwendig, manchmal sogar hinderlich. Wenn du nicht weißt, was späte Bindung ist, werte ich das als Indiz dafür, dass du es nicht brauchst. ;)
Ich habe doch in der Tat die Lösung gefunden! In VB .Net ist der Wertebereich eines Integers von -2,1 Mrd bis +2,1 Mrd, bei Access ist der Wertebereich eines Integers jedoch = dem eines Shorts in VB .Net, also -32.768 bis +32.768. Nach einem Ändern im Accress in Long Integer funktioniert das Schreiben nun erfolgreich.
Glückwunsch. Du siehst, es ist wichtig, auf die Wertebereiche der Datentypen zu achten, vor allem dann, wenn verschiedene Systeme miteinander gekoppelt werden.
Ist es heutzutage eigentlich noch wichtig, genau auf die Datentypen zu achten, oder kann man bedenkenlos Longs, Decimals und Strings verwenden? In dem VB .Net-Tutorial von diesem Forum war nämlich davon die Rede, dass man zur Sicherheit vor logischen oder mathematischen Fehlern lieber den Wertebereich einschränken sollte.
Man sollte grundsätzlich darauf achten, für welchen Datentyp bzw. Wertebereich man sich entscheidet; aus Faulheit immer Long oder Decimal zu verwenden, ist sicherlich eine schlechte Idee. Man sollte immer darauf achten, welchen Wertebereich man braucht, und dann den kleinstmöglichen dafür brauchbaren Datentyp zu verwenden. Das verringert nicht nur den Speicherverbrauch, sondern erhöht auch die Verarbeitungsgeschwindigkeit. Bei den meisten Programmen ist das zwar nicht relevant, aber man sollte sich durch die Leistungsfähigkeit der heutigen Rechner nicht zu einer Schludrigkeit verleiten lassen, die einem dann doch mitunter schwer zu findende Fallstricke in den Weg legt. Zudem ist auf eine gewisse Konsistenz zu achten, um Konvertierungen möglichst zu vermeiden.
Was fällt Microsoft eigentlich ein, die Wertebereiche vom Integer in den beiden Programmen verschieden zu definieren?
Unterschiedliche Programmiersprachen haben unterschiedliche Bezeichnungen für ihre Datentypen, daran musst du dich gewöhnen. Die Benennungen für SQL-Datenbanken stammen größtenteils noch aus der Zeit, als 32-Bit-Zahlen noch als long bezeichnet wurden; selbst Microsoft kann das nicht ignorieren. VB dagegen ist dafür geplant, die immer größere Bandbreite des Datenbusses moderner Prozessoren auch mit seinen Datentypen zu unterstützen; außerdem war der Bedarf nach Ganzzahlen mit möglichst großem Wertebereich schon immer latent vorhanden, wenn auch meistens nur bei besonderen wissenschaftlich Hochleistungs-Programmen.
 
Zurück