Ökonomische Zukunft von ADS in der Anwendungsentwicklung

[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*

[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"...

[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.

[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

[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

[joachimd]

Zitat von Frickler:

Mal ne Tabelle restrukturiert, in deren Namen ein Umlaut vorkommt? Mit purem SQL unmöglich, man muss das zu Fuß erledigen.

Sorry für die harte Kritik ... aber so einen Sch... macht man auch nicht. Objektnamen mit Umlauten anzulegen ist per Design schon ein Bug, auch wenn es möglich ist.

[joachimd]

Zitat von RSF:

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.

Wie man die ADS Komponenten in 10.1. Berlin nutzt, habe ich schon vor fast einem Jahr gezeigt: https://www.jd-engineering.de/using-...i-10-1-berlin/. Klar ist die Option FireDAC verführend, aber das Framework beherrscht halt nur den kleinsten gemeinsamen Nenner.

[RSF]

Zitat von joachimd:

Wie man die ADS Komponenten in 10.1. Berlin nutzt, habe ich schon vor fast einem Jahr gezeigt: https://www.jd-engineering.de/using-...i-10-1-berlin/. Klar ist die Option FireDAC verführend, aber das Framework beherrscht halt nur den kleinsten gemeinsamen Nenner.

Habe ich auch probiert. Habe es auch in Berlin 10.1 installieren können und funktioniert auch. Bis auf, dass die Icons der Komponenten nur als Standard-Icon angezeigt werden. Sowie bei Erzeugung meiner Anwendung unter 64Bit, es zur Fehlermeldung gekommen ist.

[dcc64 Fataler Fehler] adscnnct.pas(293): F2063 Verwendete Unit 'ace.pas' kann nicht compiliert werden