Delphi-PRAXiS
Seite 2 von 4     12 34      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Ökonomische Zukunft von ADS in der Anwendungsentwicklung (https://www.delphipraxis.net/191721-oekonomische-zukunft-von-ads-der-anwendungsentwicklung.html)

hoika 15. Feb 2017 22:22

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung
 
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 15. Feb 2017 22:35

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung
 
Zitat:

Zitat von Frickler (Beitrag 1361737)
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 16. Feb 2017 07:56

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung
 
Hallo,
Zitat:

Mit purem SQL unmöglich, man muss das zu Fuß erledigen.
Bei MS-SQL geht das mit den Sonderzeichen ...

Frickler 16. Feb 2017 08:17

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung
 
Zitat:

Zitat von Bernhard Geyer (Beitrag 1361742)
Zitat:

Zitat von Frickler (Beitrag 1361737)
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 16. Feb 2017 08:28

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung
 
Zitat:

Zitat von Frickler (Beitrag 1361737)

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 16. Feb 2017 09:41

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung
 
Zitat:

Zitat von Frickler (Beitrag 1361765)
Zitat:

Zitat von Bernhard Geyer (Beitrag 1361742)
Zitat:

Zitat von Frickler (Beitrag 1361737)
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 16. Feb 2017 10:34

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung
 
Zitat:

Zitat von hoika (Beitrag 1361738)
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.
:wall:


Gruß
K-H

joachimd 16. Feb 2017 12:21

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung
 
Zitat:

Zitat von Frickler (Beitrag 1361737)
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 16. Feb 2017 12:26

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung
 
Zitat:

Zitat von RSF (Beitrag 1361768)
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 16. Feb 2017 12:50

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung
 
Zitat:

Zitat von joachimd (Beitrag 1361813)
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


Alle Zeitangaben in WEZ +1. Es ist jetzt 07:50 Uhr.
Seite 2 von 4     12 34      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz