Wie geht es weiter mit Delphi? Ernüchternde Support-Aussagen

**Papaschlumpf73**

Da bei Windows 10 nur der SQLNCLI für SQL Server bis <=2005 mitgeliefert wird, brauchst du den SQLNCLI 2014 aber oft weiterhin. Selbst für SDAC von Devart braucht man den. Betrifft vor allem den Zugriff auf bestimmte benannte Instanzen und ab 2008 eingeführte Datentypen. Für die Datentypen kann man sich Unterstützerklassen schreiben, muss dann aber deren "As"-Eigenschaften verwenden.

Wo kriegt man den denn her? Ich dachte bei SQLNCLI 2012 ist Schluss...

**himitsu**

Zitat:

Schon damals war mir klar, dass Delphi für die Entwicklung von Datenbankanwendungen (wie) geschaffen war

ja klar ... Delphi (Turbo Pascal) wurde ja von einer Firma (Borland) übernommen, welche u.A. mit Datenbanken (Oracle) ihr Geld verdiente.

[add]

Zitat:

SDAC ist natürlich nur für MSSQL. Aber es gibt ja auch UniDac..

PgDAC uvm.

**BigAl**

Ich verwende seit etwa 15 Jahren (+/-) das SDAC von Devart für den Zugriff auf SQL-Server Datenbanken. Alle meine Anwendungen laufen bei Kunden weltweit im 7/24 Betrieb. Das ist super robust und wird auch immer noch sehr gut gepflegt (und bei Problemen erhält man schnellen Support). SDAC ist natürlich nur für MSSQL. Aber es gibt ja auch UniDac... Soviel zur Zukunftssicherheit.

Ich denke aber auch - wie meine Vorredner - dass das eher ein Designproblem ist...

**Uwe Raabe**

Zitat von Papaschlumpf73:

Eigentlich suche ich auch keine Ausweichlösung, sondern wollte mich mit euch über den generellen Umgang bei Emba mit solchen Problemen unterhalten.

Die Aussage der FireDAC-Entwickler sagt, dass er nichts tun kann muss ja nicht auf ewig so bleiben. Es ist gar nicht so unwahrscheinlich, dass das in einem zukünftigen Release gelöst wird. Manchmal sind dazu vielleicht größere Umbauten nötig, die in einem schnellen Fix nicht unterzubringen sind - wer weiß das schon.

**Papaschlumpf73**

Jedenfalls finde ich es sehr schade, dass viele Funktionalitäten, die man früher bedenkenlos einsetzen konnte, nicht mehr dem Stand der Technik entsprechen. Oft geht’s nur noch mit Gefrickel oder Komponenten von Drittanbietern.

Nur ein paar Beispiele:

Die alten OLE DB Provider funktionieren; die neuen nur mit Einschränkungen
FTP funktioniert - haut dir aber jeder Admin zurecht um die Ohren; SFTP/FTPS gibt’s nicht
WSDL-Dateien einlesen geht - sofern diese den technischen Stand von vor 15 Jahren haben. Bei Standards wie WSSecurity muss schon gefrickelt werden. Und Dateianhänge mit MTOM+XOP…

Dabei sind doch Datenbankanbindung, Datenaustausch und Webservices pure Basics, die jede Entwicklungsumgebung unterstützen sollte. Also nach heutigen Standards und nicht denen von vor 10-15 Jahren.

Vielleicht werde ich ja auch nur alt und sentimental…

**Sinspin**

Was meinst Du mit SFTP/FTPS geht nicht? Du meinst es gibt keine Komponente dafür?
Da sind wir wieder bei der Frage, was sollte bei Delphi dabei sein und was muss man zukaufen.

Keine Frage, das Internet und seine Protokolle sind Heute sowas wie das Öl im Getriebe.
Aber auch Öl kauft man zu.
Emba könnte ein Paket von Pro-Komponenten anbieten. Aber warum? Die haben sicher schon genug zu tuen die anderen Platformen aktuell zu halten.

Es gibt eine ganze Reihe Hersteller die sich seit Jahren ins Zeug legen und alle wesentlichen Protokolle implementieren. Das kostet Zeit und Geld.
Zum Beispiel /N-Software, die kenne ich seit 15 Jahren. Geht es um Kommunikation sind die mein Öl Lieferant

Umsonst sind die nicht. Aber dafür ist alles gleich aufgebaut, einfach zu verstehen und läuft stabil!

**himitsu**

Es gibt die INDY ... inzwischen sind die auch Multiplatform.

Und es gab das eigene Zeugs, wie TWebBrowser oder TNetHTTPClient, was auch Multiplatform ist.
Nur dass bei den "eigenen" Sachen schon ein bissl sehr viel fehlt.

**Papaschlumpf73**

Zitat von Sinspin:

Was meinst Du mit SFTP/FTPS geht nicht? Du meinst es gibt keine Komponente dafür?

Ja genau - also jedenfalls nicht im Delphi-Paket. Das ist halt meine Sentimentalität: Vor 25 Jahren konnte ich einfach so FTP einsetzen und das war ok. Und heute muss ich für dieselbe Funktionalität (nur eben sicherer) Komponenten woanders dazu kaufen. Es geht dabei nicht ums Geld, sondern vielmehr um den zeitlichen Aufwand - und jeder Hersteller hat so seine Eigenheiten, an die man sich gewöhnen muss. Was ist nun aus RAD geworden? Das R stand einst für Rapid - heute wohl eher für Rudimentär.

**Redeemer**

FTPS sollte mit Indy gehen, ist aber abhängig von OpenSSL.
SFTP, besser bekannt als SSH, geht ebenfalls nativ nicht kostenfrei. SSH ist aber halt auch nicht so einfach zu implementieren. Man sollte es kostenfrei mit der Putty-Suite hinbiegen können, damit hab ich bisher selbst aber nur eine SSH-Implementierung ohne SFTP gebaut.

Zitat von Papaschlumpf73:

Zitat von Redeemer:

Da bei Windows 10 nur der SQLNCLI für SQL Server bis <=2005 mitgeliefert wird, brauchst du den SQLNCLI 2014 aber oft weiterhin. Selbst für SDAC von Devart braucht man den. Betrifft vor allem den Zugriff auf bestimmte benannte Instanzen und ab 2008 eingeführte Datentypen. Für die Datentypen kann man sich Unterstützerklassen schreiben, muss dann aber deren "As"-Eigenschaften verwenden.

Wo kriegt man den denn her? Ich dachte bei SQLNCLI 2012 ist Schluss...

Hab da was durcheinander gebracht. SQLNCLI 14 heißt das Ding und ist für SQL Server 2012. Fies ist auch, dass es Regressionen gibt. Beispiel: Wir hatten bei uns in der Firma vier unterschiedliche Versionen 14.0, ich nenne sie aufsteigend nach Build A < B < C < D. A konnte etwas nicht, B und D konnten es, aber C nicht.

**Bernhard Geyer**

Zitat von Papaschlumpf73:

Die alten OLE DB Provider funktionieren; die neuen nur mit Einschränkungen

Ist nicht mittlerweile (nach MS) ODBC state of the Art.
Bin ich froh das ich die ganzen ODBCE/DAO/RDO/ADO/ADO.NET/...-Techniken nicht alle mitmachen musste

Zitat von Papaschlumpf73:

FTP funktioniert - haut dir aber jeder Admin zurecht um die Ohren; SFTP/FTPS gibt’s nicht

Bei uns wird oft HTTP-Upload genutzt. SFTP kommt selten vor.

Zitat von Papaschlumpf73:

WSDL-Dateien einlesen geht - sofern diese den technischen Stand von vor 15 Jahren haben. Bei Standards wie WSSecurity muss schon gefrickelt werden. Und Dateianhänge mit MTOM+XOP…

Ja. Die SOAP-WS ist nicht gerade das Steckenpferd. Glücklicherweise vermeiden das auch die Kunden und setzen entweder SOAP + Security über Firewalls um (Anwendung außen vor) oder setzen gleich auf REST/JSON und Co. und vermeiden SOAP mittlerweile.
Aber vor kurzen mit einer Delphi+SOAP-Client geschafft das nach eine Navision-Update nicht die ganzen WSDLs komplett anders aussahen sondern wieder den alten Stand repräsentierten.

Zitat von Papaschlumpf73:

Dabei sind doch Datenbankanbindung, Datenaustausch und Webservices pure Basics, die jede Entwicklungsumgebung unterstützen sollte. Also nach heutigen Standards und nicht denen von vor 10-15 Jahren.

Ich finde das was mit REST/JSON eingebaut wurde ganz gut.
Und in der großen Version gibts ja auch Anbindungen für die ganzen ECommerce+CRM-Lösungen "out of the box" (wobei ich die Qualität dieser nicht bewerten kann).
Und mit Devart gibts für die DB-Schnittstelle ein sehr gute Alternative. Im Beruflichen Umfeld meisten kein relevanter Kostenfaktor (wenn man gesparte Supportzeit dagegen hält).