Ökonomische Zukunft von ADS in der Anwendungsentwicklung

[Frickler]

Zitat von Der schöne Günther:

Ich würde die Komponenten (bunte Vierecke aufs Formular ziehen) nicht überbewerten. Alternativ hat FireDAC eine gute Einbindung von ADS sodass man die Komponenten nicht selber kompilieren muss.

Der "One size fits it all" Ansatz bei FireDAC kann aber gerade bei ADS nicht alles bieten, was die nativen Komponenten können. Etliche Aufgaben lassen sich gerade nicht in SQL erledigen, sondern Du musst z.B. AEPs (Advantage Extended Procedures) nutzen, die man von TAdsQuery aus aufrufen kann. Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

[hoika]

Hallo,

Zitat:

Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt?

Schon der Erzeuger der Tabelle, genauer des Tabellennamens sollte gesteinigt und gefedert werden!

Und das meine ich Ernst! *Ofen anzünd*

[p80286]

Zitat von hoika:

Hallo,

Zitat:

Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt?

Schon der Erzeuger der Tabelle, genauer des Tabellennamens sollte gesteinigt und gefedert werden!

Und das meine ich Ernst! *Ofen anzünd*

Wo ist das Problem? Access kann das problemlos, erst als (vor einigen Jahren) die Anwendung auf den MS-Sqlserver portiert wurde, hat es ein wenig Mehrarbeit gekostet. Das schlimmste war, dem Benutzer klar zu machen, daß Umlaute in Tabellennamen eben nicht vom MSSql-Server unterstützt wurden.



Gruß
K-H

[Bernhard Geyer]

Zitat von p80286:

... daß Umlaute in Tabellennamen eben nicht vom MSSql-Server unterstützt wurden.

Du meinst wohl das eure Anwendung das nicht unterstützt.
Hab gerade im 2016er ein Tabelle "Tabelle_äöü" mit Feld "äöü angelegt.
Funktioniert prächtig.

[p80286]

Zitat von Bernhard Geyer:

Zitat von p80286:

... daß Umlaute in Tabellennamen eben nicht vom MSSql-Server unterstützt wurden.

Du meinst wohl das eure Anwendung das nicht unterstützt.
Hab gerade im 2016er ein Tabelle "Tabelle_äöü" mit Feld "äöü angelegt.
Funktioniert prächtig.

2016 Jaaaa, es ist schon etwas her, so 2009/2010, da hat's dafür noch Haue gegeben.

Gruß
K-H

[Bernhard Geyer]

Zitat von Frickler:

Etliche Aufgaben lassen sich gerade nicht in SQL erledigen, sondern Du musst z.B. AEPs (Advantage Extended Procedures) nutzen, die man von TAdsQuery aus aufrufen kann. Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Dafür hat jedes DBMS ein Administrations-Tool. Das brauch ich in den wenigsten Fällen in der eigenen Anwendung.

[hoika]

Hallo,

Zitat:

Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Bei MS-SQL geht das mit den Sonderzeichen ...

[Frickler]

Zitat von Bernhard Geyer:

Zitat von Frickler:

Etliche Aufgaben lassen sich gerade nicht in SQL erledigen, sondern Du musst z.B. AEPs (Advantage Extended Procedures) nutzen, die man von TAdsQuery aus aufrufen kann. Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Dafür hat jedes DBMS ein Administrations-Tool. Das brauch ich in den wenigsten Fällen in der eigenen Anwendung.

Das kannst Du machen, wenn Du der einzige Anwender bist. Bei Kunden muss sowas automatisch ablaufen können.

@Hoika ich halte das auch für nen Bug. Denn ansonsten kann man mit solchen Tabellen mit SQL wirklich alles machen. Alles außer "Alter Table"...

[Bernhard Geyer]

Zitat von Frickler:

Zitat von Bernhard Geyer:

Zitat von Frickler:

Etliche Aufgaben lassen sich gerade nicht in SQL erledigen, sondern Du musst z.B. AEPs (Advantage Extended Procedures) nutzen, die man von TAdsQuery aus aufrufen kann. Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Dafür hat jedes DBMS ein Administrations-Tool. Das brauch ich in den wenigsten Fällen in der eigenen Anwendung.

Das kannst Du machen, wenn Du der einzige Anwender bist. Bei Kunden muss sowas automatisch ablaufen können.

Das Beispiel war aber sehr gekünstelt. Diesen habe ich so nicht.
Und die normalen Strukturänderungen machen wir ja auch Programmtechnisch.

Aber wenn DDL nur über die Spezialkomponenten möglich wäre dann war das schon eine ziemliche Einschränkung des DBMS

[RSF]

Zitat von Frickler:

Der "One size fits it all" Ansatz bei FireDAC kann aber gerade bei ADS nicht alles bieten, was die nativen Komponenten können. Etliche Aufgaben lassen sich gerade nicht in SQL erledigen, sondern Du musst z.B. AEPs (Advantage Extended Procedures) nutzen, die man von TAdsQuery aus aufrufen kann. Kleines Beispiel? Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Kann ich voll bestätigen. Ich habe versucht ADS DB mit FireDAC anzusteuern und bin enttäuscht.
Für kleinere Adressdatenbanken möge das reichen, aber bei eine komplexen DB mit Administration nicht mehr.
Einige Funktionen fehlen schlichtweg andere sind umständlich. Klar man kann es nicht jedem recht machen.
Dafür sind (waren) eben die nativen Komponenten von ADS da.
z.B
CREATE DATABASE "Datenbankxy.add" ist nicht mit FireDAC und ADS möglich
AdsConnection1.DDVersionMajor ( bzw. Minor) Funktion ist auch nicht vorhanden, nur über SQL Systemtabelle möglich

Ich hatte nach unendlichen Stunden, mit zum Teil frustrierenden Ergebnissen, einfach keine Lust mehr mein altes ADS-Projekt an Delphi Berlin (mit FireDAC) anzupassen. Es wird jetzt einfach mit Delphi XE weitergepflegt und parallel dazu auf Delphi Berlin und auf Basis von Postges neu entwickelt.