Zugriff auf SDF DB mit ADO

[Schokohase]

Zitat:

Zitat von DieDolly (Beitrag 1432153)

Zitat:

Wenn du keinen Provider installierst (und der SQL Compact wird nun mal nicht automatisch mit dem OS installiert) dann wirst du auch den nicht verwenden können. Das ist ganz einfache Logik.

Wie macht es der SdfBrowser denn? Irgendwie muss das doch zu bewerkstelligen sein. Ob jetzt ODBC, DHL oder DPD. Hauptsache ich komm auf die DB :P

Da hat sich jemand hingesetzt und einen Wrapper geschrieben mit dem man ganz gemütlich per .net auf den SqlCompact zugreifen kann als richtige embedded Lösung. (Ich vermute mal, dass das MS war).

Diese Arbeit hat sich aber niemand für Delphi gemacht.

Wenn du ungefähr wissen willst wie das so ungefähr aussehen kann, dann schaust du dir mal so einen SQlite Wrapper für Delphi an.

[DieDolly]

Zitat:

Diese Arbeit hat sich aber niemand für Delphi gemacht.

Ich kann mir denken warum. In den Köpfen der leute steckt Delphi == Pascal == sehr alt, sehr schlecht, einfach schlecht.
Alles was über normale Programme und Datenzugriff hinaus geht, scheint für Delphi schon exotisch zu sein. DevArt ist übrigens keine Lösung. Viel zu teuer.
Dann hab ich Pech gehabt. Hätte ich damals nur eine vernünftige Sprache gelernt. In meinem Alter werde ich nicht nochmal anfangen.

[EWeiss]

Zitat:

Diese Arbeit hat sich aber niemand für Delphi gemacht.

Ok nochmal.. Da es anscheinend jedes mal überlesen wurde.
DELPHI <> NET

Und es sollte mit ADO funktionieren Siehe!

gruss

[DieDolly]

Ist das nicht total egal? Ich habe Delphi, direkt neben meiner Exe liegt eine Datenbankdatei in die jedes Programm rein kann nur Delphi mal wieder nicht.
Die Datei ist ja da. Die muss ich mir nicht erst herzaubern. Und trotzdem ist Delphi zu bescheiden, um die Datei zu lesen.

Es gibt da wohl nur noch die Möglichkeit die DB in eine andere Datei oder ein anderes DB Format zu exportieren.

[EWeiss]

Zitat:

Ist das nicht total egal?

Sorry du verstehst es nicht..
Es ist nicht egal es sei denn du verwendest Delphi.Net… (Was wie ich gelesen habe ja nicht weiter entwickelt wird)

gruss

[DieDolly]

Zitat:

Sorry du verstehst es nicht..

Das stimmt. Ich verstehe es nicht. Das finde ich aber auch nicht schlimm. Ich umgehe das Datenbankproblem jetzt einfach und nutze Wege, die auch delphisicher sind.
Es geht mir drum, eine Lösung zu finden und ich glaube die habe ich jetzt. Zwar gehen mir dabei die schönen SQL-Querys verloren aber das bekomme ich auch anders hin.
Ich mache das mal fertig und zeige es dann.

[Delphi.Narium]

Es reicht nicht, dass irgendwelche DLLs von irgendwelcher Software neben irgendeiner Exe liegen.

Es muss auch irgendeine Schnittstelle (z. B. ein Wrapper für die DLLs) oder ein installierter Client oder ... vorhanden sein.

Es reicht nicht, neben ein Auto, das normalerweise mit Benzin (Delphi) fährt, einen Kanister Diesel (.net) stellt. Es wird dadurch nicht fahren.

[EWeiss]

Zitat:

Es reicht nicht, neben ein Auto, das normalerweise mit Benzin (Delphi) fährt, einen Kanister Diesel (.net) stellt. Es wird dadurch nicht fahren.

Wovon ich die ganze Zeit geredet habe.

Zitat:

Ich habe Delphi, direkt neben meiner Exe liegt eine Datenbankdatei in die jedes Programm rein kann nur Delphi mal wieder nicht.
Die Datei ist ja da. Die muss ich mir nicht erst herzaubern. Und trotzdem ist Delphi zu bescheiden, um die Datei zu lesen.

Sorry.. Und ja Delphi kann nur du weist nicht wie.. Hoffe das Hilft! ;)

Zitat:

Zwar gehen mir dabei die schönen SQL-Querys verloren aber das bekomme ich auch anders hin.

Nö die gehen nicht verloren wenn man es denn richtig macht.

Zitat:

Mein ConnectionString muss wohl so lauten wenn ich lokale DLLs verwenden und nichts installieren möchte

Nochmal! Du musst den Provider installieren die ganzen Dll's die du dort abgelegt hast sind nicht Delphi Konform.. verstehe das doch endlich.
Wenn du Spiele, spielen willst und diese verlangen die DirectX-Runtime dann musst du diese Installieren ohne funktionieren sie nicht!
Du kannst .NET nicht mit Delphi kombinieren, genauso wenig wie Quelltext von VB6 als Delphi auszugeben und dann versuchen diesen in Delphi zu kompilieren.

Zitat:

Soweit bin ich

Leider noch nicht.

Zitat:

Ich habe mir zum Test die DLL Dateien von SdfBrowser rauskopiert und neben meine Test-Exe gelegt

Brrrr..

• SdfBrowser = Net
• Test-Exe = Delphi.. Niemals wirst du eine Verbindung zwischen CSharp (C#.net) Bibliotheken und Delphi herstellen können das sind 2 paar Schuhe.

ADO
So! Hier 2 Einfache Anwendungen.
Damit du sehen kannst das es funktioniert.

1. GetProvider (source include)
2. Connect (source include)

Zu 1! Listet dir alle Provider auf die in deinem System installiert sind.
Zu 2! Liest deine Datenbank ein vorausgesetzt diese befindet sich unter D:\Database1.sdf

Mein ConnectionString!

Delphi-Quellcode:

AdoQuery.ConnectionString:='Provider=Microsoft.SQLSERVER.CE.OLEDB.4.0;Data Source=D:\Database1.sdf';

Aber ACHTUNG!
Wird der Provider Microsoft.SQLSERVER.CE.OLEDB.4.0 bei dir nicht gelistet nun dann funktioniert logischer weise die Anwendung Connect auch nicht.
Wenn nicht installiert hier geht's weiter!
Du benötigst keine externen DLL's sondern musst lediglich den Provider Installiert haben. (Die Dll's für .NET sind Wrapper und unnötig für Delphi, Delphi kann darauf nicht zugreifen weil es .NET Assembly's sind)
Siehe Shot meine Provider die auf dem System installiert sind.

PS:

Zitat:

Wie sieht das später mit der Exe aus. Ist die auf anderen Systemen abhängig von diesem Provider oder ist das dann alles fest in der Exe drin?

Die Provider werden Systemweit installiert. (Weil sie auch von anderen Anwendungen verwendet werden, das gleiche wie bei Treibern) oder legst du jede Treiber DLL in deinen Anwendungspfad?
Verstehe nicht warum du dich dagegen sträubst.
Prüfe beim Start deiner Anwendung ob dieser auf dem jeweiligen System installiert ist wenn nicht gebe ne Meldung aus mit dem Download Link zu den Provider.
Was denkst du wie die Spiele Hersteller das Handhaben wenn keins oder das falsche DirectX installiert ist.
Alles andere ist Frickelei.

Deinstalliere mal den SQL Server glaubst du dann das deine Anwendung immer noch läuft?
Und ja auch dieser ist System weit installiert.. Wenn auf dem anderen System dieser nicht vorhanden ist läuft deine Anwendung auch nicht.
Ist also gehüpft wie gesprungen. Sich gegen die Installation zu wehren (verweigern) ist Kontraproduktiv.

Das war's jetzt von mir! (Hoffe die Post wird nicht als Unfreundlich aufgefasst)

gruss