| Autor |
Beitrag |
gamoes
      
Beiträge: 86
|
Verfasst: Sa 11.03.06 00:00
Hallo,
mein DBEdit-Feld habe ich über eine DOA-Komponente an ein Float-Feld der DB angebunden. Wenn ich mir die Datensätze anzeigen lasse, dann werden mir die richtigen Float-Werte angezeigt. Will ich aber einen neuen Datensatz einfügen und in diesem Feld beispielsweise 22,75 eintragen, dann wird das Komma gar nicht angenommen und es steht dort nur 2275. Probiere ich das Ganze mit einem Punkt erhalte ich dasselbe Ergebnis.
Gruß
Gabi
|
|
MSCH
      
Beiträge: 1448
Erhaltene Danke: 3
W7 64
XE2, SQL, DevExpress, DevArt, Oracle, SQLServer
|
Verfasst: Sa 11.03.06 15:43
hmmm, DBEDIT, kann es sein, das du das falsche EditFeld nimmst?
Editfelder können zwar "Floats" anzeigen, allerdings nur "Strings" als Eingabe zulassen.
Da gibts doch eine DB-Komponente, die Zahlen und Gleitkommawerte zulässt, oder?
grez
msch
_________________ ist das politisch, wenn ich linksdrehenden Joghurt haben möchte?
|
|
gamoes 
      
Beiträge: 86
|
Verfasst: Sa 11.03.06 15:59
Es gibt noch DBRichText. Meinst Du das?
Dann gibt es ein MaskEdit, aber das ist keine DB-Komponenten
Gruß
Gabi
|
|
raiguen
      
Beiträge: 374
WIN 2000prof, WIN XP prof
D7EP, MSSQL, ABSDB
|
Verfasst: Mo 13.03.06 15:29
Moin
In der Regel wird das Komma bei der Eingabe in einem DBEdit, welches an an ein Float-Field angebunden ist, auch mit abgespeichert. Könnte evtl sein, dass die DOA-Komponenten beim Abspeichern aus welchem Grund auch immer das Komma raushaut!?
Gruß
|
|
senidex
      
Beiträge: 17
WIN XP
|
Verfasst: Mo 13.03.06 16:22
Hallo Gabi,
kannst du mir zu deinem Problem 3 Angaben machen ?
- welche Delphi-Version
- was für eine Anwendung (.NET Windows Forms,.NET VCL ...)
- was für eine Datenbank benutzt du ?
mfg
Hans
|
|
gamoes 
      
Beiträge: 86
|
Verfasst: Mo 13.03.06 17:23
Ich benutze Delphi 7 deutsch
VCL
Oracle 9.2
Gruß
Gabi
|
|
senidex
      
Beiträge: 17
WIN XP
|
Verfasst: Mo 13.03.06 17:49
Hallo Gabi,
im Prinzip darf hier kein Fehler passieren.Ich arbeite ebenfalls mit ORACLE.
Man müsste sich sonst dein Formular ansehen,ob etwas mit den Komponenten schiefgegangen ist.
Wenn ich mir das mal ansehen soll, hinterlege dieses Formular (pas+dfm) und
noch einen DESCRIBE tabellenname in SQLPlus, damit ich mir die Tabelle ansehen kann.
mfg
Hans
|
|
gamoes 
      
Beiträge: 86
|
Verfasst: Mo 13.03.06 19:35
Kannst gern mal meine Dateien anschauen.
Hab die dfm umbennenen müssen in Artikel_Formular.pas, weil dfm nicht erlaubt ist.
Die Tabelle heißt Artikel mit:
ARTNR number 10
ARTBEZ varchar2 50
NETTO float 10
MWST number 2
Gruß
Gabi
|
|
gamoes 
      
Beiträge: 86
|
Verfasst: Mo 13.03.06 22:18
Sorry, hab die Dateien nicht mit dran gehangen.
Hier also die beiden Dateien
Gruß
Gabi
Einloggen, um Attachments anzusehen!
|
|
senidex
      
Beiträge: 17
WIN XP
|
Verfasst: Di 14.03.06 09:32
Hallo Gabi,
danke für deine Dateien.
Ich habe gemerkt, dass du Oracle-spezifische TQuery-Komonenten benutzt, die ich leider nicht habe.
Vielleicht liegt darin die Ursache.
Benutze als erstes mal anstatt den Typ FLOAT den Typ NUMBER(x,y), wobei x die Gesamtanzahl der Stellen und y die Nachkommastellen sind.
Sollte dies auch nicht klappen, dann tausche die Oracle-Query mit der normalen Delphi-ADOQuery aus.
Viel Erfolg
Hans
|
|
raiguen
      
Beiträge: 374
WIN 2000prof, WIN XP prof
D7EP, MSSQL, ABSDB
|
Verfasst: Di 14.03.06 11:48
Moin
Auszug aus der Artikel.pas:
Delphi-Quelltext 1: 2: 3: 4: 5:
| procedure Tfrm_Artikel.FormShow(Sender: TObject); begin DecimalSeparator:='.'; ods_Artikel.Open; end; |
Du übersteuerst die Systemeinstellung und somit hat das Komma im DBEdit-Feld keine Chance und dann hast das 'Ergebnis' wie Du es im Eingangspostng beschrieben hast.
Frage: warum setzt Du den DecimalSeparator expliziet?
Gruß
|
|
gamoes 
      
Beiträge: 86
|
Verfasst: Di 14.03.06 15:28
Wenn ich normale ADO-Komponenten nutze dann, kann ich in dem DBEdit-Feld problemlos ein Komma eintragen.
Den DecimalSeperator hab ich genutzt, damit der zu jeder Zeit aus dem Komma ein Punkt gemacht wird. Es also nicht vorkommen kann, dass der Anwender ein Komma eingibt und das dann beim Abspeichern stehen bleibt.
Gruß
Gabi
|
|
alzaimar
      
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Di 14.03.06 15:40
gamoes hat folgendes geschrieben: | | Den DecimalSeperator hab ich genutzt, damit der zu jeder Zeit aus dem Komma ein Punkt gemacht wird. Es also nicht vorkommen kann, dass der Anwender ein Komma eingibt und das dann beim Abspeichern stehen bleibt. |
Das klappt? Ich dachte, der steuert nur, ob '12.34' oder '12,34' als Dezimalzahl interpretiert und formatiert wird.
Wenn der Anwender Punkt und Komma eingeben darf, dann musst Du das direkt bei der Eingabe umwuseln. Dazu sind die OnKeyPress-Ereignisse gut, denn die werden immer aufgerufen... wenn eben ein Key gepressed (aua) wird. Und da übersetzt Du einfach ein ',' in einen '.'. Das sollte das Problem mit dem Punkt/Komma lösen.
Delphi-Quelltext 1: 2: 3: 4:
| procedure TForm1.Edit1KeyPress(Sender: TObject; var Key: Char); begin if key = ',' then Key := '.' end; |
_________________ Na denn, dann. Bis dann, denn.
|
|
raiguen
      
Beiträge: 374
WIN 2000prof, WIN XP prof
D7EP, MSSQL, ABSDB
|
Verfasst: Di 14.03.06 16:50
gamoes hat folgendes geschrieben: | | Wenn ich normale ADO-Komponenten nutze dann, kann ich in dem DBEdit-Feld problemlos ein Komma eintragen. |
D.h. bei DOA geht das nicht!? *wunder*
gamoes hat folgendes geschrieben: | | Den DecimalSeperator hab ich genutzt, damit der zu jeder Zeit aus dem Komma ein Punkt gemacht wird. Es also nicht vorkommen kann, dass der Anwender ein Komma eingibt und das dann beim Abspeichern stehen bleibt. |
Hä!?!? Ich geb Dir insofern Recht, wenn der Wert als String abspeichert wird. Bei Float-Feldern wird das Format der zugrundeliegenden Tabelle genommen bzw. die spezifischen Einstellungen; von daher isses egal, ob Du Komma oder Punkt als DecimalSeparator nimmst. Anders ausgedrückt: die Tabellen-Einstellungen haben als DezimalSeparator einen Punkt und das DBEdit-Feld verwendet ein Komma (z.B. 12,34), dann wird der Wert in der Tabelle mit 12.34 abgespeichert.
Auf der anderen Seite 'steuert' das Setzen von DecimalSeparator die Anzeige im DBGrid oder DBEdit, sprich wenn in der Tabelle 12,34 eingetragen ist, dann wirds zu 12.34  wie alzaimer richtig angemerkt hat.
@alzaimer:
Deine OnKeyPress-Prozedure hat Gabi ja auch verwendet...
Um nochmal auf das Eingangsposting zurückzukommen:
gamoes hat folgendes geschrieben: | Hallo,
mein DBEdit-Feld habe ich über eine DOA-Komponente an ein Float-Feld der DB angebunden. Wenn ich mir die Datensätze anzeigen lasse, dann werden mir die richtigen Float-Werte angezeigt. |
D.h. in der Tabelle stehen die Werte mit Komma drin?
gamoes hat folgendes geschrieben: | | Probiere ich das Ganze mit einem Punkt erhalte ich dasselbe Ergebnis. |
Wenn der DecimalSeparator ein Komma ist (Standardwerrt im deutschen Windoews) dann isses klar, dass der Punkt nicht angenommen wird
So, genug der Verwirrungen
Gruß
|
|
gamoes 
      
Beiträge: 86
|
Verfasst: Di 14.03.06 18:18
In der Tabelle der DB steht der Wert mit Punkt drin. Er wird dann auch mit Punkt angezeigt. Trage ich einen neuen Wert ein, dann läßt sich weder der Punkt noch das Komma eintragen.
Benutze ich ADO-Komponenten, dann ich sowohl Punkt als auch Komma eintragen. Trage ich aber ein Komma ein, dann bekomme ich beim Abspeichern die Fehlermeldung, es wäre ein falscher Wert.
Deshalb wollte ich unbedingt vermeiden, dass man ein Komma im DB-Feld stehen hat.
Gruß
Gabi
|
|
raiguen
      
Beiträge: 374
WIN 2000prof, WIN XP prof
D7EP, MSSQL, ABSDB
|
Verfasst: Di 14.03.06 20:19
Moin
hmm*grübel* dann scheint das Problem mit den (dem?) DOA zusammen zu hängen
Von daher ist dann Dein 'Klimmzug' mit temporärem DecimalSeperator etc derzeit wohl eine relativ passable Möglichkeit, die Problematik zu umschiffen - zumindest so wie ich das momentan sehe. Vielleicht hat ja ein anderer User ne bessere Idee!?
Gruß
Rainer
|
|