Probleme mit langen Zahlenwerten aus einer Datenbank

Arne Danikowski · Beiträge: 194

Hallo erst einmal.
Ich bastle grade an einer Warenwirtschaft rum und stehe vor folgenden Problem.
Meine Datenbank (Access MDB) enthält mehrere Tabellen, die alle das Feld EAN enthalten.
Das Feld ist als Zahl deklariert, Dezimal, 13 Stellen, Festkommawerte.
Ich möchte einen Wareneingang realisieren.
Nun soll, wenn die EAN Nummer eingegeben wird (in der Tabelle EINGANG) mit diesem Wert in der Tabelle Artikel gesucht werden.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:

procedure Tlagereingang.RxDBGrid1ColExit(Sender: TObject);
var nummer: Cardinal;
begin
  if RxDBGrid1.Col = 1 then
  begin
  nummer:=lagerdata.ADOEingangQuery.FieldByName('EAN').AsInteger;
  Lagerdata.ADOArtikelQuery.SQL.Clear;
  Lagerdata.ADOArtikelQuery.SQL.Text:='Select * From artikel WHERE EAN = ' +IntToStr(nummer);
  Lagerdata.ADOArtikelQuery.open;
  
   if lagerdata.ADOArtikelQuery.FieldByName('EAN').AsInteger = nummer then
   begin
    lagerdata.ADOEingangQuery.FieldByName('seriennummer').AsString:=lagerdata.ADOArtikelQuery.FieldByName('serienenummer').AsString;
   end
   else
   MessageDlg('Artikel nicht gefunden', mtWarning, [mbOK], 0);
   end;
end;

Die EAN Nummern sind allerdings 13 stellig. Ich glaube, dass lagerdata.ADOEingangQuery.FieldByName('EAN').AsInteger keine so langen Zahlenwerte zuläßt.

Wenn ich den Wert, der in der Variablen nummer in ein Label ausgebe, steht dort auch eine gangz andere Zahl. Gebe ich eine Zahl mit nur 11 Stellen ein, funktioniert es.

Was kann ich tun?

alzaimar · Verfasst: Di 16.09.08 10:19

Aus der EAN-"Nummer" eine Zeichenkette machen. Denn genauer genommen ist EAN keine Zahl, sondern eine Information, die mit Ziffern kodiert ist.

_________________
Na denn, dann. Bis dann, denn.

Arne Danikowski · Beiträge: 194

und wie stelle ich das an?

alzaimar · Verfasst: Di 16.09.08 10:35

Mit Access den Feldtyp von Numerisch auf Text ändern.

_________________
Na denn, dann. Bis dann, denn.

Arne Danikowski · Beiträge: 194

Das ist eigentlich nicht möglich, da es keine EAN Nummern mit Buchstaben gibt und diese auch nicht doppelt vorkommen dürfen. (Indies. Ja ohne Dublikate)

ene · Verfasst: Di 16.09.08 11:23

Auch auf Texfelder kann man einen Index erstellen. Als Schlüssel sollten solche Zahlen auch nicht dienen. Gibt's auch EAN-Nummern mit führenden Nullen? Dann sind das keine Zahlen mehr, sondern Texte, denn 0100 gibt es nicht im dezimalen System

Long-Werte gehen nur bis 2.147.483.647, also 10 Stellen. Single und Double sind größer, aber das kann eigentlich nicht die Lösung des Problems sein.

_________________
Wir, die guten Willens sind, geführt von Ahnungslosen, Versuchen für die Undankbaren das Unmögliche zu vollbringen.
Wir haben soviel mit so wenig so lange versucht, daß wir jetzt qualifiziert sind, fast alles mit Nichts zu bewerkstelligen.

Arne Danikowski · Beiträge: 194

Ich habe die EAN Datenfelder nun mal auf den Typ TEXT umgestellt (zum testen)

ich erhalte nun folgende Fehlermeldung:

Datentypen im Kreterienausdruck unverträglich

markieren

Delphi-Quelltext

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:

procedure Tlagereingang.RxDBGrid1ColExit(Sender: TObject);
var nummer: string;
begin
  if RxDBGrid1.Col = 1 then   //Wenn Spalte 1 verlassen wird dann
  begin
    nummer := lagerdata.ADOEingangQuery.FieldByName('EAN').AsString;  //Wert der Zelle in Variable
    label1.Caption := lagerdata.ADOEingangQuery.FieldByName('EAN').AsString;  //Label zur Kontrolle benennen
    Lagerdata.ADOArtikelQuery.SQL.Clear; //Query zurücksetzen
    Lagerdata.ADOArtikelQuery.SQL.Text := 'Select * From artikel WHERE EAN = ' + nummer; //Query auf Wert der Zelle
    Lagerdata.ADOArtikelQuery.open;  //Query öffnen

    if lagerdata.ADOArtikelQuery.FieldByName('EAN').AsString = nummer then //Wenn Query = Wert der Zelle dann
    begin
      //Übergabe der Datenfelder aus Query in Datensatz der Tabelle Eeingang
      lagerdata.ADOEingangQuery.FieldByName('Seriennummer').AsString := lagerdata.ADOArtikelQuery.FieldByName('Seriennummer').AsString;
      lagerdata.ADOEingangQuery.FieldByName('Artikelnummer').AsString := lagerdata.ADOArtikelQuery.FieldByName('Artikelnummer').AsString;
      lagerdata.ADOEingangQuery.FieldByName('Model').AsString := lagerdata.ADOArtikelQuery.FieldByName('Model').AsString;
      lagerdata.ADOEingangQuery.FieldByName('Kategorie').AsString := lagerdata.ADOArtikelQuery.FieldByName('Kategorie').AsString;
      lagerdata.ADOEingangQuery.FieldByName('Hersteller').AsString := lagerdata.ADOArtikelQuery.FieldByName('Hersteller').AsString;
    end

    else // Wenn Query Artikel nicht = Wert der Zelle
      if MessageDlg('Artikel nicht gefunden? Soll er neu angelegt werden?', mtConfirmation, [mbOK, mbCancel], 0) = mrOK
        then
      begin
        lagerschnelleingabe.Showmodal;
      end;
end;

Arne Danikowski · Beiträge: 194

Ok Dummheit muss bestraft werden muss natürlich

markieren

Delphi-Quelltext

1:	Lagerdata.ADOArtikelQuery.SQL.Text := 'Select * From artikel WHERE EAN = ' +QuotedStr(nummer);

ene · Verfasst: Di 16.09.08 12:01

markieren

Delphi-Quelltext

1:	Lagerdata.ADOArtikelQuery.SQL.Text := 'SELECT * FROM artikel WHERE EAN = "' + nummer + '"';

Texte müssen immer in Hochkommata oder Anführungszeichen. Siehe auch hier in der Mitte. In VBA nimmt immer die Hochkommata, weil die Anführungszeichen Strings begrenzen. Bei Delphi ist es andersrum.

Edit: Oder so, wie in deinem Beispiel, dafür mach ich zu wenig mit DB's unter Delphi

_________________
Wir, die guten Willens sind, geführt von Ahnungslosen, Versuchen für die Undankbaren das Unmögliche zu vollbringen.
Wir haben soviel mit so wenig so lange versucht, daß wir jetzt qualifiziert sind, fast alles mit Nichts zu bewerkstelligen.

alzaimar · Verfasst: Di 16.09.08 12:28

Es ist immer besser, 'parametrisierte Queries' zu verwenden. Schau mal hier im Forum nach diesem Schlagwort. Denn dann übernimmt Delphi/ADO die korrekte Formatierung (Hochkommata, Gänsefüsserl, Komma/Dezimalpunkt etc.) für Dich..

Im Prinzip geht es so:

markieren

Delphi-Quelltext

1:
2:
3:

MyQuery.SQL.Text := 'select * from Foobar where Field = :MyParam';
MyQuery.Params.ParamByName('MyParam').FieldType := ftString; // oder heißt das 'Datatype' ?
MyQuery.Params.ParamValues['MyParam'] := 'MeinText';

Du sagst ADO also, um was für einen Parameter es sich handelt (String, Nummer, Datum etc.) und ADO fragt die Datenbank, wie man soetwas formatiert (bzw. weiss es einfach).

Ganz speziell bei Datumsen (Mehrzahl von 'Datum') ist das praktisch, denn Access ist da ziemlich exotisch...

_________________
Na denn, dann. Bis dann, denn.

ene · Verfasst: Di 16.09.08 12:32

alzaimar hat folgendes geschrieben:

Ganz speziell bei Datumsen (Mehrzahl von 'Datum') ist das praktisch, denn Access ist da ziemlich exotisch...

Warum? Ist halt ds amerikanische Jet-SQL, welches sich nicht nach den PC-Einstellungen richtet

(mm/dd/yy) oder (yyyy-mm-dd)

_________________
Wir, die guten Willens sind, geführt von Ahnungslosen, Versuchen für die Undankbaren das Unmögliche zu vollbringen.
Wir haben soviel mit so wenig so lange versucht, daß wir jetzt qualifiziert sind, fast alles mit Nichts zu bewerkstelligen.

alzaimar · Verfasst: Di 16.09.08 12:36

markieren

SQL-Anweisung

1:	select * from tabelle where datum = #2008/04/19#

Die '#' hatten mich um den Verstand gebracht. Woher weisst Du eigentlich, welches Datumsformat deine DB nun versteht?

_________________
Na denn, dann. Bis dann, denn.

ene · Verfasst: Di 16.09.08 13:30

Gemein wäre, weil ich die Werkzeuge zu nutzen weiß
Böse wäre, weil ich die Tasten meiner Tastatur zu benutzen weiß
Und Tatsache ist, ich arbeite fast ausschließlich mit Access und MS SQL-Servern. Da lernt neben dem Datum, dem "." auch noch den Unterschied zwischen ADO und Jet kennen, ist leider etwas inkosistent, aber was solls. P-SQL empfinde ich auch nicht als das Beste vom Besten. Die "#" hättest du herausgefunden, wenn du mal ein Datum in einer Abfrage als Kriterium verwendest und dann die SQL-Ansicht auswählst. Aber die Parametergeschichte ist oftmals die bessere, auch wenns etwas mehr Tipperei ist. Gibt's in Access ja auch.

_________________
Wir, die guten Willens sind, geführt von Ahnungslosen, Versuchen für die Undankbaren das Unmögliche zu vollbringen.
Wir haben soviel mit so wenig so lange versucht, daß wir jetzt qualifiziert sind, fast alles mit Nichts zu bewerkstelligen.

alzaimar · Verfasst: Di 16.09.08 14:01

ene hat folgendes geschrieben:

Gemein wäre...Böse wäre...

Richtig wäre:

Ich, wer sonst hat folgendes geschrieben:

Das ist sehr kniffelig, Weil ich das gar nicht ohne Weiteres für alle DB-Versionen wissen kann (Werkzeuge oder Tastatur bedienen hin oder her), denn meine Applikation soll auch in der inneren Mongolei auf einem PC mit tschechischem Windows laufen, der von einem uzbekischen User bedient wird, der in seinen persönlichen Einstellungen aber das Datumsformat für Suaheli eingestellt hat und neben Access, FireBird auch ein ADS, Nexus, MSSQL, DB2 und SAPDB am Laufen hat, nur um mich zu ärgern. Und die Anwendung soll -bitteschön- mit allen DB klar kommen.

ene hat folgendes geschrieben:

Die "#" hättest du herausgefunden, wenn du mal ein Datum in einer Abfrage als Kriterium..

Mein Post impliziert, das ich irgendwie auf die '#' gekommen bin. Wie wohl?

_________________
Na denn, dann. Bis dann, denn.

ene · Verfasst: Di 16.09.08 14:30

IMHO wäre das Access herzlich egal. Bei uzbekisch und Suaheli bin ich mir nicht sicher, aber bei Englischem und Deutschem Win ist das herzlich egal, wenn man sich an ein paar Grundregeln hält.

Und bei den Parametern geb ich dir im Allgemeinen immer noch recht.

_________________
Wir, die guten Willens sind, geführt von Ahnungslosen, Versuchen für die Undankbaren das Unmögliche zu vollbringen.
Wir haben soviel mit so wenig so lange versucht, daß wir jetzt qualifiziert sind, fast alles mit Nichts zu bewerkstelligen.

alzaimar · Verfasst: Di 16.09.08 16:27

Ich bastle mir meine SQL-stmts auch immer so zurecht, wenn ich garantiert eh nur mit MSSQL arbeite. Access lehne ich aus ästhetischen Gründen ab. Außerdem würden mich meine Frau und meine Kinder dann (glaub ich) verleugnen.

_________________
Na denn, dann. Bis dann, denn.

Arne Danikowski · Beiträge: 194

OK Danke für die Antworten.
(Hätte ja nicht gedacht, dass das wieder eine Grundsatzdisskusion auslöst

)

Ich habe das nun so gelöst.

Den Feldtyp auf Text umgestellt und die Eingabe unter Delphi auf Zahlenwerte beschränkt.
Funktioniert Basta.

mfg

P.S. thx alzaimar

alzaimar · Verfasst: Di 16.09.08 17:21

Arne Danikowski hat folgendes geschrieben:

(Hätte ja nicht gedacht, dass das wieder eine Grundsatzdisskusion auslöst

)

Wir sind halt eine basisdemokratische WG in der Alles in der Küche mit einem Jogi-Tee ausdiskutiert wird.

_________________
Na denn, dann. Bis dann, denn.

hansa · Beiträge: 3079 Erhaltene Danke: 9

alzaimar hat folgendes geschrieben:

..Access lehne ich aus ästhetischen Gründen ab. Außerdem würden mich meine Frau und meine Kinder dann (glaub ich) verleugnen.

Du hast sogar die schon soweit dressiert ? :shock:

Den Access Schamass könnt ihr euch allerdings tatsächlich selber um die Ohren hauen. :lol:

Das hier ist allerdings äußerst gefährlich ;

Arne Danikowski hat folgendes geschrieben:

Das ist eigentlich nicht möglich, da es keine EAN Nummern mit Buchstaben gibt und diese auch nicht doppelt vorkommen dürfen.

Das mit den Buchstaben stimmt, das andere aber nicht. So jedenfalls nicht ohne weiteres. Teil der EAN-Nr. ist auch der Lieferant/Hersteller. Und ich glaube nicht, dass die Aldi -Milch in Hamburg von derselben Kuh kommt, wie die in München. :lol:

Na gut, sagen wir Molkerei. Die hat zwar dieselbe Verpackung, EAN dürfte ja muss sogar je nach Region anders sein. Die EAN-Nr. ist also mehrdeutig !! Für Artikel+Lieferant+Verpackung+Größe+XY ist die eindeutig. Für den Artikel an sich aber nicht !

_________________
Gruß
Hansa

Arne Danikowski · Beiträge: 194

Das ist soweit richtig. Ich meine aber die EAN Nummer insgesamt. Also alle 13 Stellen dürfen nicht übereinstimmen.
Teile sind davon natürlich ausgenommen.
Jedenfalls dürfen in meiner Datenbank auf keinen Fall identische EAN Nummern vorkommen. Jeder Artikel muss zwingend eine
eigenständige EAN Nummer haben.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme