dBase III + TcxGrid und damit rechnen ?

[terra]

Hallöle zusammen !

Habe über Access 2007 eine Datenbankstruktur erstellt, worin mehrere Währungsfelder vorhanden sind, die im letzten Feld zusammenaddiert werden sollen.

Das letzte Feld (Summe) habe ich mit "Feld berechnen - Währung" erstellt, das folgenden Eintrag enthällt:
[BRUTTO]+[TUF]+[PORTO]+[EXTRA]+[PROVISION]+[KARTON]

Habe das nach der Access Hilfe erstellt. Leider rechnet er aber dort nichts zusammen.
Funktioniert dieses nicht automatisch? Muss ich noch etwas in Delphi beachten?

Die Datenbank rufe ich in Delphi mit TDataSource und TTable auf. Soweit funktioniert auch alles. Nur das automatische addieren der Felder nicht.

Kann mir da wer helfen ?

Terra

[Alfredo]

In der Überschrift steht dbase III und im Text Access 2007?

Gruß
Alfred

[terra]

Öhm jooo...

Hab mit dem Microsoft Access 2007 Programm aus dem Office Paket eine Datenbank erstellt und das ganze exportiert als dBase III.

War das falsch?

Terra

[terra]

hallöle ! ... müsste doch irgendjemand wissen, oder ?

terra

[Bernhard Geyer]

Wieso überhaupt noch dBase? Wenn Du schon Access zur verfügung hast dann nimm das. Ist das kleinere übel. Eigentlich muss man mit jeder Delphi-Version damit rechnen (und ich hoffe es auch) das endlich die BDE mit dem dBase/Paradox-Support komplett stirbt/eingestellt wird.

[Alfredo]

dbase und Delphi funktioniert nur mit ADS richtig.

Bei Access habe ich mit der Version 2002 aufgehört.
Informationen zu den Bugs bei den einzelnen Versionen
gibt es bei Karl Donabauer(www.donkarl.com).

Zugriff auf Access mit TAdoconnection.
Zum Testen unter connectionstring Datenverküpfungsdatei verwenden.
Bei mir erschien DBDemos.udl.

Wenn es nicht Access sein muss, dann verwende Firebird.

Gruß
Alfred

[mkinzler]

Für den einfachen Zugriff könnte auch TDbf helfen. Ich würde aber auch auf ein zeitgemässes DBMS setzen.

[terra]

Hallöle !

Also, ich bin jetzt umgestiegen von DBase auf Access selbst. Hat auch den schönen Vorteil, das ich mehrere Tabellen in eine Datenbank packen und das besser händeln kann. Muss dazu sagen, das dies mein erstes Programm ist, wo ich überhaupt was mit Datenbanken mache.

Wie auch immer. Klappt alles ganz gut mit TAdoconnection und was man sonst noch braucht. Jetzt kommt aber eine kleine Sache, die ich noch nicht verstehe. In der Access Datenbank ist alles supi eingerichtet läuft auch. Sprich, er rechnet automatisch !

Ich habe im Delphi Programm eine Tabelle und eine extra Eingabemaske. Trage ich nun in der Eingabemaske die Daten ein, kann ich gleichzeitig in der Tabelle sehen, wie die Daten eingetragen werden. Ist ja auch egal. Er rechnet aber nicht sofort zusammen. Erst nach einem Neustart des Programms sehe ich, das mein Prog. die berechneten Werte in der Tabelle übernommen hat.

Heist also, er rechnet, schreibt es auch in die Datenbank aber zeigt mir die Werte erst in der Tabelle an, wenn diese neu geladen wird.
Gibt es da ein Trick um das sofort anzeigen zu lassen?

Habe es schon mit .refresh in der Tabelle sowie bei der DB versucht. Hilft alles nichts.

Achso, kleinigkeit noch nebenbei ... Arbeite ja, wie gesagt, mit mehreren Tabellen. kann mir wer verraten, wie ich in allen Tabellen, wenn ich in der Haupttabelle ein neuen Datensatz anlege, in den anderen Tabellen automatisch ein Datensatz mit der Artikelnummer des Hauptdatensatzes angelegt wird ?



Terra

[mkinzler]

Access hat aber auch seine Tücken. Ich würde gleich auf was Richtiges setzen. Zudem würde ich mich mit den datenbankgrundlagen auseinander setzen.

[Alfredo]

Teste einmal ob es genügt

bei Table oder Query: Active auf false und denn wieder auf true zu setzen

oder Connection: Connected auf false und dann wieder auf true zu setzen

Ergänzt um 15:11

AdoTable kennt ein Requery.


Alfred

[Bernhard Geyer]

Hat evtl. mit dem bescheuderten Cachingverhalten der JET-Engine zu tun.

[terra]

Also, was habe ich bis jetzt gemacht - bzw. was habe ich?

Komponenten
---------------------
- TADOConection
- TADODataSet
- TDataSource

- TcxGrid (DEV Express)

DataSet ist mit Connect verbunden, DataSource mit DataSet und Grid mit Source. Geht halt nicht anders aber klappt.

Der Connectstring sieht wie folgt aus:

Delphi-Quellcode:

constr := 'Provider=Microsoft.ACE.OLEDB.12.0;'+
            'User ID=Admin;'+
            'Data Source='+datapath+'data.accdb;'+
            'Mode=ReadWrite;'+
            'Jet OLEDB:System database="";'+
            'Jet OLEDB:Registry Path="";'+
            'Jet OLEDB:Database Password="";'+
            'Jet OLEDB:Engine Type=6;'+
            'Jet OLEDB:Database Locking Mode=1;'+
            'Jet OLEDB:Global Partial Bulk Ops=2;'+
            'Jet OLEDB:Global Bulk Transactions=1;'+
            'Jet OLEDB:New Database Password="";'+
            'Jet OLEDB:Create System Database=False;'+
            'Jet OLEDB:Encrypt Database=False;'+
            'Jet OLEDB:Don''t Copy Locale on Compact=False;'+
            'Jet OLEDB:Compact Without Replica Repair=False;'+
            'Jet OLEDB:SFP=False;'+
            'Jet OLEDB:Support Complex Data=False;';

- AutoCalcFields sind aktiviert.




Wie wende ich denn dieses Requery denn an?
Hab aber gesehen, das ADODataSet dies auch unterstützt. Kann damit aber nichts anfangen. Sorry.

Kann auch wer mir meine andere Frage oben beantworten?

LG Terra

[Alfredo]

Für den ersten Test einfach ein Button auf die Form
und dann

Delphi-Quellcode:

Dataset1.Requery;

[terra]

Habe ich gemacht - geht leider nicht.

Der genaue Ausdruck lautet: .Requery(Options: TExecuteOptions=[]); und befindet sich in der TADODataSet Komponente. Habe es erstmal mit DataSet.Requery(); probiert. Brachte kein Ergebniss.

Ich könnte ja jetzt auch hergehen und nur die Values der Eingabemaske zusammenrechnen und in die Tabelle als Value schreiben. Dann wäre ja zumindest was zu sehen. Aber das ist ja sicherlich nicht im Sinne des Erfinders alles doppelt und dreifach zu machen. nur langsam fällt mir keine andere Lösung zu dem Problem ein.

Terra

[Alfredo]

Warum verwendest Du nicht TAdoconnection und TAdotable?

Ich komme beruflich heute leider nicht dazu dass alles zu testen.

[mkinzler]

Von einer xxTable würde ich Abstand nehmen

[Bernhard Geyer]

TAdotable ist eine Ableitung von TADODataSet.
Ist (bei voll gepatchten VCL) ziemlich egal was man nimmt. Für neuprojekte sollte man nur TADODataSet nehmen da man sich nur die Properties von einem Klasse merken muss.

[Alfredo]

Was mir an den Ausführungen von terra nicht einleuchtet ist, warum er sagt
dass er TAdoConnection und TAdoDataset verwendet.

Ich habe es einmal ausprobiert, TAdoDataset reicht doch alleine aus.

Wurden denn die Daten überhaupt in Access hineingeschrieben?

Delphi-Quellcode:

AdoDataset1.post;

Delphi-Quellcode:

AdoDataset1.Requery();

funktioniert bei einer Datenänderung einwandfrei.

Die Berechnung einer Spalte habe ich noch nicht getestet.

[Bernhard Geyer]

Zitat:

Zitat von Alfredo (Beitrag 1040815)

Wurden denn die Daten überhaupt in Access hineingeschrieben?

Delphi-Quellcode:

AdoDataset1.post;

sollte doch:

Zitat:

Zitat von terra (Beitrag 1040815)

Trage ich nun in der Eingabemaske die Daten ein, kann ich gleichzeitig in der Tabelle sehen, wie die Daten eingetragen werden. Ist ja auch egal. Er rechnet aber nicht sofort zusammen. Erst nach einem Neustart des Programms sehe ich, das mein Prog. die berechneten Werte in der Tabelle übernommen hat.

Heist also, er rechnet, schreibt es auch in die Datenbank aber zeigt mir die Werte erst in der Tabelle an, wenn diese neu geladen wird.

[Alfredo]

Zitat:

Zitat von terra

Trage ich nun in der Eingabemaske die Daten ein, kann ich gleichzeitig in der Tabelle sehen, wie die Daten eingetragen werden.

M.E. sieht er da nur dass sein Dataset geändert ist.

Mir ist nicht klar wie denn eine Berechnung in einer Access-Tabelle erfolgen
soll. Mein Kenntnisstand ist, dass dies im Rahmen einer Abfrage erfolgt.

Mir ist auch nicht verständlich warum die Berechnung nicht in Delphi erfolgt und
dann in das Feld geschrieben wird.

[terra]

Ohjemine, da habe ich ja was losgetreten ^^

Zitat:

Mir ist nicht klar wie denn eine Berechnung in einer Access-Tabelle erfolgen
soll.

Also eine Berechnung in der Access Datenbank erfolgt über den Ausdruckgenerator. Ist echt ne tolle Sache. Musste mich da aber auch erstmal reinfriemeln.

Zitat:

Mir ist auch nicht verständlich warum die Berechnung nicht in Delphi erfolgt und
dann in das Feld geschrieben wird.

Warum auch, wenn das schon die Datenbank macht und mir dadurch Quelltextschreiberei erspaart wird?

Zitat:

Was mir an den Ausführungen von terra nicht einleuchtet ist, warum er sagt
dass er TAdoConnection und TAdoDataset verwendet.
Ich habe es einmal ausprobiert, TAdoDataset reicht doch alleine aus.

Du hast schon recht, aber ich benutze nicht nur eine Tabelle sondern gleich 5! Da ist es einfacher, ein mal ein ConnectString zu schreiben und diese auf die Tabellen zu verteilen. (Der ConnectString läuft außerdem Dynamisch - je nach Pfadangebe (siehe mein letzten Delphi-Quellcode)).

Terra

[Alfredo]

Zitat:

Zitat von terra

Also eine Berechnung in der Access Datenbank erfolgt über den Ausdruckgenerator. Ist echt ne tolle Sache. Musste mich da aber auch erstmal reinfriemeln.

In Access 2002 gibt es leider diesen Feldtyp(berechnen) nicht.
Dadurch bin ich natürlich auf dem Schlauch gestanden.

Im Internet finden sich zahlreiche Hinweise, das es bei größeren Datenmengen zu Performanceproblemen kommt, weil ja die Berechnung für jeden Datensatz jedesmal neu durchgeführt werden muss.

Ich möchte nicht wissen wie da so gerechnet und gerundet wird. Excel lässt grüßen.

Bei Festplatten im TB-Bereich macht dass m.E. alles keinen Sinn.

Einmalig eine Zeile Programmcode ist auch nicht die große Arbeit.

Offensichtlich wird in deinem Fall die Berechnung nicht angestossen, weil
Access 2007 nicht läuft.

[terra]

Zitat:

Offensichtlich wird in deinem Fall die Berechnung nicht angestossen, weil Access 2007 nicht läuft.

Da habe ich mal ein Test gemacht. Ob der jetzt aber so Sinnvoll ist, steht in den Sternen.
Habe ein Datensatz mit meinem Programm in die Datenbank geschrieben. Sofort danach die Datenbank mit dem Office Access geöffnet und geschaut, was er gemacht hat. Ich konnte sehen, das er logischerweise den Datensatz hinzugefügt und auch die Berechnung durchgeführt hat.

Jetzt kann es aber durchaus sein, das durch das öffnen der Datenbank die Berechnung vollzogen wurde und nicht beim speichern in meinem Programm.

EDIT: Ich werde Wahnsinig ! ... Es war ein Hacken, der gestört hatte.
In der TcxGridDBTableView war unter DataController -> DataModeController bei dem Feld SmartRefresh ein Hacken gesetzt. Habe den einfach mal aus neugier entfernt und was macht er? Er zeigt mir in der Tabelle sofort die berechneten Werte.
Wer soll denn sowas wissen?

Ich Danke allen, die versucht haben zu helfen! DANKESCHÖN ! :-D

Terra

[Alfredo]

Zitat:

Zitat von terra

Feld SmartRefresh ein Hacken

Schön wenn dein Problem nun gelöst ist.

Ich verwende DevExpress Quantumgrid 6.
Bei mir steht das Feld SmartRefresh per default auf false.

Gruß
Alfred

[terra]

Ich schätze mal, das ich es mal ausversehen reingemacht und nicht wieder rausgenommen habe.

Kleinigkeit noch ...
Wenn ich mein Programm auf einem anderen Rechner aufspielen möchte, muss ich dort folgendes noch installieren? http://www.microsoft.com/downloads/d...b-84b371ede16d
Oder doch eher die Access Runtime 2010 ?

Hab es heute mal in der Firma probiert und da sagte mir mein Programm, das der Provider nicht gefunden werden konnte. Mir ist es da aber nicht Möglich gewesen, den Link dort auszuprobieren.

Wäre echt fein, wenn mir das noch wer sagen könnte.

LG Terra

[Alfredo]

Wenn Du Access 2007 hast, dann sollte m.E. auch die Runtime 2007 sein.

Was ich so gelesen habe, beinhaltet die Runtime auch den Provider.

Er sollte aber eigentlich auch mit den Office-Programmen auf den Rechner
gekommen sein.

Ich habe das alles in der Praxis nicht mehr ausprobiert, weil mich diese
Runtime-Geschichte und auch die ODBC-Treiber schon von den Grundlagen her
nicht überzeugt haben(genau Deine Probleme habe ich so bei mir erwartet).
Ganz besonders nett wird es, wenn ein anderes Programm eine andere Runtime
auf den Rechner installiert.

Wenn Du einmal mit einem sauber installierten Firebird-Server und mit dem
Reportgenerator Fastreport gearbeitet hast, dann wirst Du Access nicht mehr
verwenden. Mit DevExpress hast Du doch schon einen Ferrari gekauft und Fire-
bird ist kostenlos. Nur die Zugriffkomponente ist noch zu erwerben.

[terra]

Hallöle nochmal.

Wollte nur noch auf das letzte eine Antwort geben, im Falle, es möchte jemand anderes noch wissen.

Mit Microsoft Access Database Engine 2010 geht es ohne Probleme. Sind auch nur 26MB, was auch ggf. schnell runtergeladen - bzw. in eine Setup Routine eingebaut ist.



Möchte aber auch hier gerne noch etwas wissen. Vielleicht kannst du mir Alfredo einfach eine PN schicken, wenn es hier nicht mehr reinpasst.
Also, in wie weit ist Firebird besser?? Ich bin erlich gesagt schon mit dem Access 2007 ziemlich begeistert. So wenig Arbeit hatte ich noch nie. Ich glaube, wenn ich mich damit noch besser auskennen würde, wäre meine Arbeit noch schneller fertig.

So wie ich es sehen konnte ist Firebird nicht anders als MySQL vom Aufbau her. Und ich muss sagen, das ich diese manuelle schreiberei schon in PHP absolut hasse. Ich habe das Firebird nicht installiert, bin da nur mal drübergeflogen auf der Seite. Kann auch durchaus sein, das ich mich irre.

Für meine Projekte sind außerdem Datei-Datenbanken zwingend notwenig! Datenbanken im Sinne von MySQL (ggf. Firebird) bringen mir überhaupt nichts.

Kannst mir ja paar Unterschiede zwischen Access und Firebird zeigen.

Achso, ja, ich habe auch FastReport. Arbeite mich da grade für ein aktuelles Projekt rein.

Terra

[mkinzler]

Zitat:

Mit Microsoft Access Database Engine 2010 geht es ohne Probleme. Sind auch nur 26MB

FireBird sind 7 MB.

Zitat:

Also, in wie weit ist Firebird besser??

Es handelt sich hier um ein richtiges Mehrbenutzer-DBMS. Access ist eigentlich mehr das Frontend um eine weniger leistugsfähige singleuser Datenbank (JET)

Zitat:

Für meine Projekte sind außerdem Datei-Datenbanken zwingend notwenig!

Warum das?
Access ist gesauso eine Datei, wie z.B. FireBird.

Es gibt aber auch Admintools für FireBird, in denen man sich Datenbanken zusammenklicken kann ( IBExpert, FlameRobin, ...) oder auch Access verwenden.

[terra]

Zitat:

Es handelt sich hier um ein richtiges Mehrbenutzer-DBMS. Access ist eigentlich mehr das Frontend um eine weniger leistugsfähige singleuser Datenbank (JET)

Mag sein, das wir jetzt ein wenig nebenher reden aber nur von Single User Datenbank kann ich bei Access nichts sehen. Kann von verschiedenen Standorten mit dem selben Proramm auf ein und die selbe DB drauf zugreifen. Und das gleichzeitig! Mag vielleicht nicht sehr sauber sein aber für meine Zwecke reicht es aus.

Zitat:

Access ist gesauso eine Datei, wie z.B. FireBird.

Haste Falsch verstanden. Ich brauche für meine Projekte eine Datenbank. Diese DB besteht aus nur einer Datei. (oder evtl. aus zwei. z.B. DATEN.DB) ... Möchte es für den Endkunden so einfach wie möglich halten. Und meißt ist es doch so, das "der Kunde" gar kein Hintergrundwissen hat. Installieren kanner aber wie verrückt und von daher ist es simpler ein 2. "Treiberprogramm" zu installieren als wenn er erst eine komplette Datenbank konfigurieren muss um diese zu verwenden.

Von daher sehe ich mich im Moment mit Access auf der richtigen Seite.

"Möchte die Gelder meiner Firma auch nicht weiter belasten. :D Denke mal, das ich mit dem was ich habe, schon sehr zufrieden sein und auch damit gut arbeiten kann. Delphi 2010 Architect, Dev Express Paket, FastReport, und Eureka Log. Natürlich noch das neuste Office Paket und so gehören auch dazu. Jetzt muss ich aber auch Ergebnisse zeigen und das so schnell wie möglich."


Gruß, Terra

[mkinzler]

Zitat:

Mag sein, das wir jetzt ein wenig nebenher reden aber nur von Single User Datenbank kann ich bei Access nichts sehen. Kann von verschiedenen Standorten mit dem selben Proramm auf ein und die selbe DB drauf zugreifen. Und das gleichzeitig!

Es gibt aber keinen sauberen Mechanismus für diesen Multiuser-Zugriff. Zudem ist die Gefar sehr groß, dass die mdb irgendwann zerschossen ist.

Bei FireBird braucht man bei der Verwendung des embedded gar nichts installieren ( Client mit embedded Server ist eine Dll + VC Runtime Dlls und evtl. locales). Der richtige Server ist auch schlank und benötigt auch keine aufwendige Konfiguration. Der Code läuft ohne Anpassungen auf beiden Varianten.

Du scheinsrt dich aber so auf Access eingeschossen zu haben, dass du dich mit den Alternativen nicht wirklich beschäftigen willst.

[terra]

Zitat:

Du scheinsrt dich aber so auf Access eingeschossen zu haben, dass du dich mit den Alternativen nicht wirklich beschäftigen willst.

Das ist so nicht ganz richtig. Mir fehlt aber im Moment die Zeit dazu. Und jetzt nochmal das ganze Projekt zu überarbeiten, damit es auf Firebird läuft wäre zu Zeitaufwändig.

Ich lasse mich gerne eines besseren belehren. Garkeine Frage! Nur muss ich mich auch damit erst beschäftigen und wissen, wie man damit arbeitet. Bei Access habe ich ja jetzt meine Erfahrungen gemacht und kann damit einigermaßen mit umgehen. Auch, wenn ich dabei noch nicht alles verstehe aber es geht vorran.

Zumal kommt das Problem mit der Datenbankübername hinzu. Wir haben Kunden, die z.B. gerne ein altes Programm, das sie benutzt haben - neu haben möchten. Wie z.B. mein aktuelles Projekt für ein Optiker. Die haben bis jetzt mit einem Uralt Programm gearbeitet das an die guten alten DOS Zeiten erinnert. :D Das einzige Programm, was schnell und anständig die alte dBase DB übernommen hat war halt Access (ich weiß, Excel öffnet es auch). Darum bin ich halt darauf hengen geblieben. Zumal möchte ich auch die aktuelle DB Passwort schützen, damit da kein Kunde rumfummeln kann. Hatte es schon erlebt, das jemand darin rumgemacht hat und danach natürlich garnichts mehr ging.

Wie gesagt. Ich bin nicht stur auf etwas ausgerichtet und lasse mir nichts sagen. Nur für eine Umstellung brauche ich einen triftigen Grund und natürlich auch Zeit um ein Programm zu entwickeln.

Terra

[mkinzler]

Mit einer entsprechender DataPump bekommst du dBase Daten in jedes DBMS. Aber das ist imho schon der erste Fehler, denn dBase Daten aus alten Programmen haben selten eine richtig normalisierte Struktur.
Übernimmst man diese Daten 1:1 übernimmt man auch diese "Fehler". Ich würde in einem solchen Fall die Struktur analysieren und diese dann optimieren und an die neue Features neuerer DBMS anpassen und dann eine Übernhameroutine schreiben, mit der ich die Datn in die neue Struktur bekomme.

Diesen Aufwand würde ich auch treiben, denn so äuft das Programm später mit großer Wahrscheinlichkeit besser.

[terra]

Zitat:

Ich würde in einem solchen Fall die Struktur analysieren und diese dann optimieren...

Das böse Access 2007 hat mir da schon sehr geholfen. :-D
Ne, im ernst. Also sowas mache ich grundsätzlich vorher, da alle Daten natürlich auch zuletzt wieder passen müssen. Habe ja gesehen das es bei dBase anscheinend keine AutoID gab. Zumindest war nichts davon in dem aktuellen Projekt zu sehen. Macht ja nichts, es war ja jetzt außerdem mein erstes Projekt was mit dBase gearbeitet hat. Schlimmer noch ist, das das alte Optiker Programm mit sagenhaften 50 einzelnen Datenbank-Dateien gearbeitet hat, die jetzt schön in einer einzigen Access DB eingepflegt wurden. ;)

Terra

[mkinzler]

Dass spricht aber für eine vorhandene Normalisierung

[p80286]

[QUOTE=terra;1045165]

Zitat:

..Das einzige Programm, was schnell und anständig die alte dBase DB übernommen hat war halt Access (ich weiß, Excel öffnet es auch)...

Aus eigener leidvoller Erfahrung, solange Access sich mit kleinen (ca 65000 Datensätzen) Datenbeständen beschäftigt ist es durchaus brauchbar, wenn man sich einen Überblick verschaffen will. Sollen die Ergebnisse zuverlässig sein, kann ich nur von ACCESS abraten. (Sortierung unvollständig / nicht alle Datensätze aus Abfrage ausgegeben etc.) Langfristig lohnt sich die Einarbeitung in FB oder ein anderes "echtes" DBMS.

Gruß
K-H