AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

Ein Thema von Bbommel · begonnen am 10. Jan 2019 · letzter Beitrag vom 10. Jan 2019
Antwort Antwort
Seite 1 von 2  1 2   
Bbommel

Registriert seit: 27. Jun 2007
Ort: Köln
424 Beiträge
 
Delphi 10.3 Rio
 
#1

MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

  Alt 10. Jan 2019, 10:12
Datenbank: MS SQL • Version: 2008 und neuer • Zugriff über: ADO, SDAC
Hi zusammen,

seit Jahren greife ich mittels ADO recht problemlos auf MS SQL-Datenbanken zu (TADOConnection, TADOQuery). Einsatzzweck ist dabei im Wesentlichen der Import und tw. Export von größeren Datenmengen von und in diverse ERP-Systeme.

Nun möchte ich wesentliche Bestandteile des Codes zukünftrig aber auch für eine Linux-Anwendung benutzen können und ein großes Hindernis ist dabei im Moment noch die Nutzung von ADO. Eine andere Datenbankkomponente soll also her. Neben der Anforderung, dass sie also betriebssystem-unabhängig funktionieren muss, soll es auch (wie bisher) so sein, dass beim Benutzer der bisherigen Windows-Anwendung nicht noch irgendwelche anderen Bibliotheken installiert werden müssen, das Programm soll also weiterhin "einfach so" funktionieren. Wegen der erwähnten Datenmengen wäre eine gute Performance bei solchen Operationen auch gut. Perspektivisch wäre es ideal, wenn die Komponente auch mit einer Datenbank in der Cloud (also diesem Azure-DB-Zeugs, weiß gerade den tollen Markennamen nicht ) umgehen könnte.

Da ich bisher für eine Anbidnung an Postgres schon eine Lizenz für pgDAC habe, wäre es jetzt für mich naheliegend, auch für die MS SQL-Anbidnung auf DevArt zu setzen. Das müsste doch passen, oder? Vielleicht folgende konkrete Fragen dazu:
  • Preislich würde es sinnvoll sein, anstelle von SDAC und pgDAC dann UniDAC zu kaufen - gibt es da wesentliche technische Unterschiede?
  • Kann SDAC oder UniDAC mit Azure SQL umgehen, hat da jemand Erfahrungen?
  • Gäbe es eine sinnvolle Alternative, z.B. FireDAC? Da müsste man auf jedem Client irgendwelche Datenbankbibliotheken installieren, wenn ich das richtig sehe, oder?

Danke fürs Lesen, freue mich auf eure Antworten.
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.295 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#2

AW: MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

  Alt 10. Jan 2019, 10:21
Der Vorteil von DevArt ist die Möglichkeit ohne den "Client" vom Hersteller zu funktionieren.

Wenn Du schon pgDAC hast würde ich zu UniDAC raten. SDAC/pgDAC dienen dann als Provider für UniDAC.
Miniaturansicht angehängter Grafiken
unidac.jpg  
Markus Kinzler
  Mit Zitat antworten Zitat
rokli
Online

Registriert seit: 21. Mär 2009
Ort: Rödinghausen
195 Beiträge
 
Delphi 10.3 Rio
 
#3

AW: MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

  Alt 10. Jan 2019, 12:10
Hallo,

nach der BDE habe ich auch ADO verwendet - meistens erfolgreich, manchmal mit Problemen.

Dann bin ich zu FireDAC gewechselt und bin sehr gut zufrieden.

Von DevArt hab ich mir UniDAC auch angesehen - es ist m. E. dem FireDAC ähnlich und auch sicher sehr gut (weiß ich u. a. von einem VS Programmierer, der viel mit den DevArt Komponenten erledigen DB, GRID etc.). Und von der Preispolitik (Delphi ohne FireDAC bei Prof Version) ist das für meine Begriffe auch interessant.
Rolf
wenn nicht anders angegeben, schreibe ich zu D7, XE2 und MS SQL - ansonsten fragen Sie ihren Administrator oder einen Operator. Update 06/2019: Delphi 10.3 Rio,Enterprise
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.295 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#4

AW: MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

  Alt 10. Jan 2019, 12:33
FireDAC ist eine "Abspaltung" vom Vorgänger von DevArt.
Markus Kinzler
  Mit Zitat antworten Zitat
jsheyer

Registriert seit: 9. Jun 2005
Ort: Jüchen
54 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#5

AW: MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

  Alt 10. Jan 2019, 12:42
FireDAC ist doch das ehemalige AnyDAC was nicht von DevArt war/ist oder irre ich mich da??
Jörg Heyer
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.295 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#6

AW: MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

  Alt 10. Jan 2019, 12:51
Der Entwickler von AnyDAC war ein Entwickler bei CoreLabs (heute DevArt) und hat nach seinen Abschied DA-Soft gegründet.
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

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

AW: MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

  Alt 10. Jan 2019, 12:59
Nach deiner Beschreibung sollte eigentlich nur ADO.Query.xx durch NeueKomponente.query.xx ersetzt werden.
Gut auch die Connection, aber da wahrscheinlich nur eine Procedure betroffen. Wäre es da niht vollkommen egal welche du nutzt? Du müßtest Keine Rücksicht auf DBGrid und Konsorten nehmen, ich würde da keine OneForAll-Komponente nuzen.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Schokohase

Registriert seit: 17. Apr 2018
780 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#8

AW: MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

  Alt 10. Jan 2019, 13:06
Wenn man da jetzt eh dran rum bauen muss, dann sollte man auch die Chance nutzen und es gleich vernünftig umbauen.

Keine direkten Abhängigkeiten mehr von den Zugriffskomponenten.
(scheint selbst 2019 keine Selbstverständlichkeit zu sein)
  Mit Zitat antworten Zitat
Bbommel

Registriert seit: 27. Jun 2007
Ort: Köln
424 Beiträge
 
Delphi 10.3 Rio
 
#9

AW: MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

  Alt 10. Jan 2019, 13:42
Danke für eure bisherigen Rückmeldungen.

Weil ja doch hier und da mal FireDAC erwähnt wurde: mit einer Enterprise-Lizenz wäre es ja auch kein Problem, das einzusetzen. Aber wenn ich das bei einem ersten (allerdings relativ schnellen) Test richtig gesehen habe, setzt FireDAC ja irgendwelche Client-Komponenten voraus, die man vorher installieren müsste, richtig? Das wäre für mich schon ein recht starkes Argument für DevArt.

@p80286: Genau, es gibt keine Abhängigkeiten zu irgendwelchen visuellen Komponenten, insofern ist es tatsächlich relativ egal - aber trotzdem muss ich mich ja letztlich für eine bestimmte Komponente entscheiden.

@Schokohase: Ich hätte wetten können, dass von irgendwem dieser Hinweis kommt. Ja, viele Import-Routinen von mir sind schon mit einer neutralen Importer-Klasse umgesetzt und dort ist die Ergänzung einer weiteren oder der Austausch einer existierenden DB-Komponente natürlich besonders leicht. Die übrigen Import-Routinen, die bisher noch direkt über die ADOQuery zugreifen, würde ich bei dieser Gelegenheit wahrscheinlich auch entsprechend umbauen - wäre dann jetzt etwas mehr Arbeit, hat sich aber den existierenden umgestellten Routinen schon mehrfach gelohnt. Aber letztlich war das ja nicht die Kernfrage, sondern die Suche nach der Komponente, die letztlich den eigentlichen Zugriff machen soll.
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Santa Marta / Colombia
359 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#10

AW: MS SQL: Wechsel von ADO zu SDAC, UniDAC oder sonstwas?

  Alt 10. Jan 2019, 13:51
Zu deiner Frage mit Azure, UniDAC kann das wohl laut Webseite. SDAC sicherlich nicht.
Ich nutze seit Jahren UniDAC und bin sehr zufrieden, Performance mässig sollen die wohl die Besten sein.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

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:

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