TDbf: Zahlen-Felder in dBase immer NUMERIC, kein AutoInc?

Für Themen zu Datenbanken und Zugriff auf diese. Auch für Datenbankkomponenten.
Antworten
LigH
Beiträge: 25
Registriert: Mi 20. Sep 2006, 09:54

TDbf: Zahlen-Felder in dBase immer NUMERIC, kein AutoInc?

Beitrag von LigH »

Nachdem ich mit dem Zugriff auf MySQL arge Schwierigkeiten hatte, hab ich's erst mal mit TDbf versucht, so zwischendurch. Aber auch hier komme ich schon wieder in Schwierigkeiten. Die dürften allerdings bereits in der Verwaltung von dBase-Dateien liegen...

Ich habe die Tabellenstruktur in Access 2000 vorbereitet und dann als dBase IV exportiert. Ein ID-Feld ist dabei in der Access-Datenbank vom Typ AutoInc (Long Integer). Es werden drei Dateien (DBF, IDX, MDX) erzeugt.

Ich weiß ja nicht, ob es am Export liegt, oder ob dBase grundsätzlich nur den Feldtyp "NUMERIC" kennt (nicht Integer) - jedenfalls wird beim Öffnen für dieses Feld der TFieldType "ftFloat" ermittelt, anstatt "ftAutoInc".

- Kann Lazarus eigentlich auch Paradox-DBs verwalten?

- Vielleicht versuch ich's am Ende auch noch mit ODBC in Access...

jb
Beiträge: 17
Registriert: Di 30. Jan 2007, 22:34
OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
CPU-Target: xxBit
Wohnort: Ladbergen

Beitrag von jb »

dbase kennt kein Autoinc (zumindest nicht bis Version IV)
Aber normalerweise kannst du AutoInc in Numeric konvertieren, nur bei der Neuanlage musst du selbst für den neuen Wert sorgen (also zB letzten Satz indiziert über das AutoInc Feld lesen, und 1 draufaddieren)

LigH
Beiträge: 25
Registriert: Mi 20. Sep 2006, 09:54

Beitrag von LigH »

jb hat geschrieben:dbase kennt kein Autoinc (zumindest nicht bis Version IV)

Dann bestünde also für V5 noch geringe Hoffnung?! :D

Ich brauche eigentlich vor allem ein AutoInc-Feld zum Neuanlegen, denn ich kann mich nicht adrauf verlassen, dass der höchste zur Zeit verwendete Feldindex auch der höchste jemals benutzte war.

Das Erstellen von CSV-Tabellen mit SDF ist auch alles andere als geeignet. Ich brauche doch C/S-DBs.

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

Kann Lazarus eigentlich auch Paradox-DBs verwalten?

Ich hab anfang der Woche n ParadoxdataSet geschrieben findest du auf http://www.ullihome.de
Ist aber read-only eigentlich eher gedacht um alte datenbestände importieren zu können.

Mit dem Problem mit den AutoIncs kannst du dich ja mal an Tony Maro wenden der verwaltet tdbf seit n paar jahren kannst ja aber vorher noch mal die aktuelle version verwenden villeicht ists da schon behoben.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Beitrag von af0815 »

Das mit den AutoInc ist eine philosophische Frage - Wie lege ich mein Design an.

Du kannst statt einem AutoInc genausogut eine Unique Idetifier erzeugen und diese statt einer AutoInc verwenden. Vorteil davon ist, das absolut eindeutig bist. Oder du berechnest dir die Nummer selbst (ev. Generator).

Ist einfach, mach eine Tabelle, in der du dir die Tabellenamen und die letzte verwendete ID hinterlegst, wennst du eine neue benötigst, schau dort nach, ehöhe sie und verwende die neue ID. Das ganze innerhalb einer Transaktion und du hast das Problem der AutoInc nicht.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

schnullerbacke
Beiträge: 1187
Registriert: Mi 13. Dez 2006, 10:58
OS, Lazarus, FPC: Winux (L 1.2.xy FPC 2.6.z)
CPU-Target: AMD A4-6400 APU
Wohnort: Hamburg

Beitrag von schnullerbacke »

Aber wenns denn C/S sein soll, sollte man von DBASE und Konsorten ganz die Finger lassen. ODBC ist für mich auch eher ein Blinddarm, es gibt ja immerhin for free PostgreSQL, Firebird, MySQL und OpenInterbase. Die sind alle von Hause aus C/S-fähig und erzeugen ihre Genaratoren und Trigger freiwillig wenn man das geeignete Tool verwendet (IBExpress für Firebird, PGAdmin III für PostgreSQL). Und die 10-15 MB mehr auf der Platte machen den Kohl auch nicht mehr fett.

DBASE ist auch nicht mehr wirklich zeitgemäß, wer bei C/S unter DBASE schonmal minutenlang vor einer scheinbar toten Anwendung gesessen hat, weiß was ich meine.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.

(Ringelnatz)

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Beitrag von Christian »

schnuller wir reden hier aber über die lazarus tdbf komponente und nicht üer die bde und konsorten.
mein altuelles projekt ne warenwirtschaft besser ein rewrite dieser da das noch alles delphi code war unterstützt unterschiedliche dbs schnittstellen. und über die tdbf komponente kann man mit bis zu 5 leuten sogar gut arbeiten und das ungefähr 10x schneller als mit der bde darüber würd ich auch nur noch sql dbs benutzen aber tdbf ist genial weil kein server, keine einrichtung für einzelplatzanwendung oder kleine betriebe einfach genial. auch wenn man beim programmiern schon über stolpersteine fällt aber immerhin das system läuft.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

Antworten