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 :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

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 :

1	CLng(Val(txtPaketnummer.Text)) & ", " & _

den Befehl

Code :

1	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

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.

Zitat von Vereth

Man verwendet vernünftigerweise auch weder Access noch VB

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

Zitat von Vereth

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?

Zitat von Vereth

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?

Zitat von Vereth

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?

Zitat von SonMarcel

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

Der Spaß sei dir gegönnt

Zitat von SonMarcel

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.

Zitat von SonMarcel

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.

Zitat von SonMarcel

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.

Zitat von SonMarcel

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.

Zitat von SonMarcel

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.