TDFTable erkennt AutoInc Felder nicht

[Sinspin]

Hallo,

ich ziehe gerade in mein größtes Projekt (500K LOC) FireDAC als Zwischenschicht zum Zugriff auf die DB ein.
Bisher war es Advantage Database Server im Direktzugriff, jetzt via FireDAC.

Nun ist mir etwas sehr merkwürdiges aufgefallen.
Mit TFDQuery wird mir beim öffnen einer Tabelle ein enthaltenes AutoInc Feld korrekt als TFDAutoIncField erzeugt.
Mache ich das gleiche mit TFDTable kommt TIntegerField bei raus.

Führe ich ein Insert aus, wird mir via Query correkt ein neuer Record erzeugt, nach Post stehe ich auch drauf.
Bei der Tabelle geht es in die Hose, mir wird jedesmal der erste Datensatz in der Tabelle überschrieben und geliefert.

Was ich beim besten Willen nicht verstehe, warum TFDQuery es hinbekommt, TFDTable nicht.
Connection und Tabellen sind unverändert. Nur halt Connection auf ADS driver.

Woran kann das liegen?

Ich verwende Delphi 10.3 Update 3, wohl dann auch FireDAC in der Version. ADS ist 11.10.0.24.

[Uwe Raabe]

Ist in FetchOptions.Items das fiMeta gesetzt?

[Sinspin]

Jawoll, fiMeta ist gesetzt. Das hatte ich auch schon gefunden.

Hier mal die DFM Auszüge aus meinem Test. Da würde man alle Änderungen sehen die ich an den Komponenten gemacht habe.
Und man kann sehen was die Komponenten an Feld info erzeugt haben.

Code:

object Query: TFDQuery
  Active = False
  Connection = TestConnection
  SQL.Strings = (
    'Select * from contacts')
  Left = 287
  Top = 578
  object QueryID: TFDAutoIncField
    FieldName = 'ID'
    Origin = 'ID'
    ProviderFlags = [pfInWhere, pfInKey]
    ReadOnly = True
  end
end
object Table: TFDTable
  Active = False
  Connection = TestConnection
  UpdateOptions.UpdateTableName = 'Contacts'
  TableName = 'Contacts'
  Left = 335
  Top = 578
  object TableID: TIntegerField
    FieldName = 'ID'
    Origin = 'ID'
  end
end

Für alle anderen felder werden die gleichen FeldTypen erzeugt.
Allerdings werden bei TFDTable für keines der Felder "ProviderFlags" geliefert.

[himitsu]

Da ist doch bereits ein TIntegerField (FieldName "ID") eingebaut.

Lösche das mal. (ich denke die FDTable wird den Field-Typ nicht eigenständig böswillig ändern wollen)
Oder ändere dessen Typ zu TFDAutoIncField (in der DFM. in der PAS könnteste das auch machen, aber beim Speichern bietet dir Delphi eh an den Typ anhand der DFM zu ändern)

[Sinspin]

Genau. Das Integer Feld wurde so erzeugt als ich Felder abgerufen habe. Für die Query das erwartete TFDAutoIncField. Für die Tabelle eben nicht.

[RSF]

Ich denke mal FireDAC hat nicht den vollständigen Funktionsumfang für ADS als die
originalen ADS Komponenten. Den schließlich sind ADS Datenbanken eigentlich tot.:pale:
Das wird zwar die Frage nicht beantworten
aber erklärt vielleicht warum FireDAC für ADS nicht vollkommen ist.

[Sinspin]

Wie kommst du darauf?
Wenn Emba Geld für ein Produkt nimmt (und nicht gerade wenig) dann sollte das auch zu 100% funktionieren.
Und, solange ein Produkt verkauft wird halte ich es auch nicht für tot.

[RSF]

Zitat:

Zitat von Sinspin (Beitrag 1482636)

Wie kommst du darauf?
Wenn Emba Geld für ein Produkt nimmt (und nicht gerade wenig) dann sollte das auch zu 100% funktionieren.
Und, solange ein Produkt verkauft wird halte ich es auch nicht für tot.

Erstens verkauft EMBA keine ADS Datenbanken.8-)
Zweitens siehe hier:https://www.delphipraxis.net/191721-...twicklung.html

Mit besten Grüßen
Ronald

[Uwe Raabe]

Zitat:

Zitat von Sinspin (Beitrag 1482612)

Was ich beim besten Willen nicht verstehe, warum TFDQuery es hinbekommt, TFDTable nicht.

Wenn niemand hier eine Erklärung hat (und ADS ist tot gilt nicht), wäre vielleicht ein QP-Eintrag hilfreich.

[RSF]

Ich glaube nicht das noch jemand eine Korrektur/Erweiterung an Komponenten (FireDAC) für eine veraltete Datenbank (ADS) vornimmt.
Aber die Hoffnung stirbt zuletzt.
Ich hatte viele Jahre mit ADS gearbeitet. Alle Projekte wurden bei mir auf eine noch „lebende“ DB umgestellt.
Ich hatte einige Gespräche mit meinen Ansprechpartnern bei SAP.
Warum verwendet er nicht einfach die Originalen Komponenten Bibliothek von ADS?

[Sinspin]

Ich rede hier nicht von einem Kinderkram Projekt. Da würde ich mir keinen Kopf machen.
Das ist eine über viele Jahre gewachsende Anwendung die im produktiven Einsatz ist. Wenn FireDAC als Zwischenschicht drinne ist bin ich einen Schritt weiter.
Ich kann zwar auch dann nicht einfach mal so auf eine andere DB umspringen, aber es wird leichter.

Datenbanken werden zwar alt, so wie Programmiersprachen auch. Aber tot sind sie erst wenn sie nicht mehr im Einsatz sind.

Zitat:

Zitat von Uwe Raabe (Beitrag 1482644)

Wenn niemand hier eine Erklärung hat (und ADS ist tot gilt nicht), wäre vielleicht ein QP-Eintrag hilfreich.

Uwe, es ist eher so, wenn du keine Erklärung hast, dann bleibt mir nichts anderes übrig als Emba zu fragen. :wink:

[Uwe Raabe]

Zitat:

Zitat von Sinspin (Beitrag 1482653)

Uwe, es ist eher so, wenn du keine Erklärung hast, dann bleibt mir nichts anderes übrig als Emba zu fragen. :wink:

Ich arbeite selbst nicht mit ADS, insofern kann ich nur generelle Hinweise geben. Bei einem QP-Eintrag zu FireDAC klinkt sich in der Regel Dmitry selbst ein. Häufig kann er auch einen Workaround liefern, wenn man nicht auf das nächste (oder übernächste) Release warten kann.

[RSF]

Kleine Info wegen der angegebenen ADS Versionsnummer 11.10.024
letzte mir bekannte ADS Versionen:

ADS 11.10.030 ( vom 08.01.2016)
ADS 12.0.2.0 ( vom 17.11.2017)

(mein letzter Download Stand Jan 2020 von SAP)

Ronald

[Sinspin]

In den ADS eigenen Komponenten funktioniert alles wie erwartet.
FireDAC unterstützt laut Webseite alles ab Version 8.0. Also spielt es keine Rolle ob ich 11 oder 12 verwende.

Zitat:

Zitat von Uwe Raabe (Beitrag 1482662)

Ich arbeite selbst nicht mit ADS, insofern kann ich nur generelle Hinweise geben. Bei einem QP-Eintrag zu FireDAC klinkt sich in der Regel Dmitry selbst ein. Häufig kann er auch einen Workaround liefern, wenn man nicht auf das nächste (oder übernächste) Release warten kann.

Schon klar, wer verwendet noch ADS:gruebel:?
Da bei RIO (Zumindest in meiner Pro version) keine FireDAC sourcen dabei sind kann ich nicht nachsehen wo es wirklich herkommt.
Ich habe daher aktuell zwei mögliche Lösungen im Kopf. Beide sind :kotz:
Ich werde also mal Emba bemühen.
Danke Uwe.

[joachimd]

Zitat:

Zitat von Sinspin (Beitrag 1482670)

Schon klar, wer verwendet noch ADS:gruebel:?

Ich ;)

[RSF]

Zitat:

Zitat von joachimd (Beitrag 1482680)

Zitat:

Zitat von Sinspin (Beitrag 1482670)

Schon klar, wer verwendet noch ADS:gruebel:?

Ich ;)

Das kann ich verstehen.
Deine Fachbeiträge und Bücher habe ich gern gelesen.:thumb::thumb::thumb:
Diese waren immer eine wertvolle Hilfe für mich.
Aber die Zeit steht nun mal nicht still. Weshalb ich auch auf eine andere DB umsteigen musste.

[joachimd]

Ich würde für eine professionelle Software auch wechseln.
Momentan brauche ich die DB nur für interne Projekte und da ist der Local Server mehr als praktisch. Ich habe ein wenig mit anderen Sachen rumgespielt, wurde aber nie so richtig warm damit. Irgendwie war alles zu umständlich (Grundfunktionalität in Interbase nur über Zusatzmodule) oder zu wenig (sqllite mit Datentypen, Triggern, Stored Procedures, Functions). Vielleicht bin ich aber auch einfach zu alt und zu verbohrt für etwas grundlegend neues ;)

[RSF]

Entschuldigung für das nachfolgende OT .
Geht mir auch so, es viel mir nicht leicht.
ADS war sehr gut. Ich habe auch lange andere DB ausprobiert, bin nun bei Postgres hängen geblieben. Nicht gerade ein Leichtgewicht. Mittlerweile komme ich damit sehr gut zurecht.