CAO - FAKTURA

Wenn ich in Access 2010 die Tabelle "journalpos" über die ODBC Datenverbindung verknüpfe, erscheint folgende Fehlermeldung.

"Die Genauigkeit des Dezimelfelds ist zu klein, um die von Ihnen hinzufügende Zahl aufzunehmen."

Die Datenverbindung hab ich mit dem ODBC Treiber 3.x und 5.x getestet. In diversen Foren schreibt man, dass es mit dem Punkt bzw. Komma zusammenhängt. (Länderspezifisch) Ich kann aber nicht in der MYSQL Feldtypen ändern, denn das dürfte eher ungünstige Auswirkungen für die CAO Software haben.

In die HeidiSQL kann ich die Tabellen öffnen....

Kann aber nicht sein, dass man heutzutage in Access oder Excel die "journalpos" Tabelle nicht importieren kann oder?

Für eine Hilfe wär ich sehr Dankbar....

Beste Grüße
Renè

BITTE BITTE
nimm keine gebunden Tabellen

mach den datenzugriff per VBA - und schreib die daten in ein recordset oder whatever du willst
von dort mach weiter

natürlich muss jeder schreibzugriff dann extra erfolgen. und gebunde formulare kannst im grunde vergessen.
dafür kannst die MEISTEN bugs umschiffen bzw du wirst immer wieder auf problemchen mysql / vba / access stossen die kannst nur auf vba level korrigieren

ich sag nur datum )))

Hallo,

wenn ich ODBC in Verbindung mit CAO lese, sträuben sich mir die Nackenharre, da einfach nicht gewährleistet ist, das die Daten korrekt bleiben.
Leider habe ich schon des öfteren erlebt, das die Datenbank inkonsistent war, nachdem per ODBC Daten geändert wurden.
Wenn es um reine Auswertungen geht, sollte man besser über den Export die Daten übergeben, oder sich dort die Daten per RBuilder aufbereiten.

Hallo,

die ODBC wollten wir nur für Auswertungen in Excel verwenden. Uns ist schon klar, dass eine Datenänderung per ODBC ein Knieschuß ist.
Inzwischen haben wir die "FlySpeed SQL Query" entdeckt und darin kann man auch mit wenig SQL Kenntnissen die CAO Daten nach Excel exportieren.

Außerdem möchte ich noch ein großes Lob für die Hilfe im Forum aussprechen! Danke für alle, die immer wieder weiterhelfen!!!

Beste Grüße
René

Nein Momment Leute

ODBC ansich ist nix böses, es ist ein reines Dateninterface.

Ihr verwechselt hier gebundene ODBC Daten - hier wird die ODBC Verbindung direkt an irgendwelche Controls wie zb Listen oder Tabellen in Excel oder Access gebunden.
Das ist böse weil MS versucht hier eine normale JEt Datebank zu simulieren. Das funktioneir thint und vorn nicht vom locking gar ned erst zu reden.

Anders ist es wenn man zb die daten direkt in ein recordset lädt über eine eigene ODBC verbindung.
Sowas wie
dim myset as adodb.recordset

myset = function-sql-query("select * from soweiso")

bzw umgekehrt

aw vba
wobei ich fürs schreiben eingene collection mache
sprich ich schick jeweils einen string als collection.property pro insert
erst wenn alles fertig ist mach ich eine sql verbindung - schalte transcations nach verfügbarkeit ein - und lass eine schleife laufen die alle werte der colletion ein einem schwups sendet.
ist nicht nur sehr schnell zusammen mti transaktionen auch 100% bulletproof - natürlich kann man dann auch gleich die jeweiligen rows locken wenn man über mehere tabellen schreibt weil collections einen index haben - man kann isch damit dann auch komplexe vorgänge sequentiell abarbeiten

im grunde funktioniert dann odbc ned anders als cao es macht über den delphi mysql connector
delhi kann ja selber auch kein mysql ))
in beiden fällen bedient man sich eines connectors (ob nun odbc oder delphi eigener ist ziemlich wurscht) und lädt dann jeweils in sein anwendungs spezifisches datenarray/datenobject die gewünschten daten um umgekehrt schreibt sie aus einem objekt oder array zurück zum connector.

im prinzip wird dann je operation eine verbindung aufgebaut (daher empfiehlt es sich bei vielen row inserst das nicht einzeln abzuarbeiten ))