AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Ökonomische Zukunft von ADS in der Anwendungsentwicklung

Ökonomische Zukunft von ADS in der Anwendungsentwicklung

Ein Thema von RSF · begonnen am 13. Feb 2017 · letzter Beitrag vom 17. Feb 2017
Antwort Antwort
Seite 2 von 4     12 34   
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
5.607 Beiträge
 
Delphi XE4 Professional
 
#11

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung

  Alt 15. Feb 2017, 23:22
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*
Heiko
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
Ort: Oberreichenbach
15.644 Beiträge
 
Delphi XE6 Professional
 
#12

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung

  Alt 15. Feb 2017, 23:35
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.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
5.607 Beiträge
 
Delphi XE4 Professional
 
#13

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung

  Alt 16. Feb 2017, 08:56
Hallo,
Zitat:
Mit purem SQL unmöglich, man muss das zu Fuß erledigen.
Bei MS-SQL geht das mit den Sonderzeichen ...
Heiko

Geändert von hoika (16. Feb 2017 um 09:06 Uhr)
  Mit Zitat antworten Zitat
Frickler

Registriert seit: 6. Mär 2007
Ort: Osnabrück
50 Beiträge
 
Delphi 10.1 Berlin Professional
 
#14

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung

  Alt 16. Feb 2017, 09:17
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"...
  Mit Zitat antworten Zitat
RSF

Registriert seit: 13. Mär 2008
Ort: Frankenberg(Sa.)
67 Beiträge
 
Delphi 10.1 Berlin Professional
 
#15

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung

  Alt 16. Feb 2017, 09:28

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

Geändert von RSF (16. Feb 2017 um 09:32 Uhr) Grund: kleine Änderung
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
Ort: Oberreichenbach
15.644 Beiträge
 
Delphi XE6 Professional
 
#16

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung

  Alt 16. Feb 2017, 10:41
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
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
5.258 Beiträge
 
Delphi 7 Personal
 
#17

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung

  Alt 16. Feb 2017, 11:34
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
Programme gehorchen nicht Deinen Absichten
sondern Deinen Anweisungen
Do it with Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von joachimd
joachimd

Registriert seit: 17. Feb 2005
Ort: Starzach-Börstingen
542 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#18

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung

  Alt 16. Feb 2017, 13:21
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.
Joachim Dürr
Joachim Dürr Softwareengineering
http://www.jd-engineering.de
  Mit Zitat antworten Zitat
Benutzerbild von joachimd
joachimd

Registriert seit: 17. Feb 2005
Ort: Starzach-Börstingen
542 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#19

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung

  Alt 16. Feb 2017, 13:26
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.
Joachim Dürr
Joachim Dürr Softwareengineering
http://www.jd-engineering.de
  Mit Zitat antworten Zitat
RSF

Registriert seit: 13. Mär 2008
Ort: Frankenberg(Sa.)
67 Beiträge
 
Delphi 10.1 Berlin Professional
 
#20

AW: Ökonomische Zukunft von ADS in der Anwendungsentwicklung

  Alt 16. Feb 2017, 13:50
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
Ronald
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:14 Uhr.
Powered by vBulletin® Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2017 by Daniel R. Wolf