Zitat von
Bodenseematze:
Bezieht das jegliche VARCHAR-Spalten mit ein? Oder nur die "langen"?
Bezieht sich wohl auf alles, was nicht einer festen Länge entspricht. Und da fällt halt VarChar (leider) auch drunter.
Diese Frage verstehe ich nicht so recht. Bei den mir bekannten
BDE-Komponenten TTable und TQuery gibt es keine Möglichkeit um jeweils
SQL-INSERT/-UPDATE/-DELETE-Statements anzugeben.
Man kann über das TQuery-Property
UpdateObject
DeleteSQL, InsertSQL und ModifySQL-Statements angeben;
s.a.
https://docwiki.embarcadero.com/Libr...t.UpdateObject
Und so ein UpdateObject habe ich bei
TADOQuery
nicht gefunden...
EDIT: auch FireDAC hat in seiner
Query-Klasse
TFDQuery
ein
UpdateObject
; auch die Interbase-Variante hat sowas - nur eben anscheinend die
ADO-Variante nicht...
Zitat von
Bodenseematze:
..., das bedeutet doch aber, dass man die Speicherung (wenn der SELECT auf einem nicht updatebare
DB-View stattfindet) manuell machen muss, oder?
ja.
Das wäre doof - aber natürlich machbar (ggf. über eine Ableitung...)
Eigentlich ja. Wie kommen denn momentan die Daten in die Paradoxtabellen? Werden die Daten überhaupt zwingend als Datenbankdateien auf der Festplatte benötigt?
Vergiss' mal die
Paradox-Tabellen - die sind "flach" und tabellenmäßig einfach und werden mit technischen Berechnungsergebnissen direkt vor dem Aufruf von CrystalReports gefüllt; dafür werden z.Zt. TTable-Objekte verwendet...
Die o.a. TQuery sind für die Abfrage und Änderung der Daten vom MS-SQLServer da - das ist (datenbanktechnisch) der wesentlich komplexere Teil...
Wenn nein, sollte es möglich sein an der Stelle, an der momentan die Daten in die Paradoxtabellen kommen, TClientDataSet bzw. TJvMemoryData (oder alles, was "irgendwie" von TDataSet abgeleitet wurde und nur im Speicher vorhanden ist) einzusetzen.
Ich bin da auf der Suche nach Beispielen / Erklärungen, wie das über Master-/Detail-Beziehungen mit Bezügen zu "echten" Datenbank-Datasets inkl. am besten gemacht wird...
Ich habe da noch eine (automatische) Hintergrund-Auswertung der TField-Objekte auf den Masken um geänderte Datenbankfelder optisch zu markieren - das sollte damit natürlich auch noch funktionieren / durdchführbar sein
Statt
Paradox per
BDE wäre aber auch noch der Einsatz von
TDBF möglich.
Das schaue ich mir auf jeden Fall mal genauer an - das DBF-Format wäre tatsächlich eine Option; wobei dann ca. 150 Reportdateien angepasst werden müssten - das ist dann auch wieder eine nicht zu unterschätzender Aufwand.
Da gefällt mir die Möglichkeit, das über MS
Paradox ODBC-Treiber zu lösen, wesentlich besser
