Zugriff auf SDF DB mit ADO

[EWeiss]

Zitat:

PS: Bei einem 64-Bit OS musst du die x64 Variante von SQL Compact herunterladen und installieren. Dabei wird der x32 und x64 Provider installiert.

Richtig! Denn die x86 kann auf einem x64 System gar nicht installiert werden.

gruss

[EWeiss]

Zitat:

Zitat von hoika (Beitrag 1432139)

Hallo,
vielleicht hast Du (EWeiss) ja noch ein altes Dotnet-Frame drauf (3.5).

Nö.. > 4.0
Aber einige Programme(Abhängigkeiten) benötigen nun mal das 3.5 Framework und wenn es dann unter Win10 nicht aktiviert ist funktionieren diese halt nicht.

gruss

[DieDolly]

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

Zitat:

'Provider=Microsoft.SqlServerCe.Client.4.0;Data Source=db.sdf'

Aber das klappt natürlich nicht da die exe die DLL Dateien nicht sieht die direkt neben ihr liegen. Jetzt weiß ich gar nicht mehr weiter. System.Data.SqlServerCe in der Uses liste geht natürlich auch nicht.

[EWeiss]

Zitat:

Source=db.sdf'

sollte das nicht
Source=Database1.sdf'

lauten?

gruss

[DieDolly]

Ich versichere dir, das ist nicht das Problem ;)
Das Problem ist, dass der Provider nicht gefunden wird. Installieren möchte ich nichts um keine Abhängigkeiten zu erzeugen. Die SqlCE DLLs liegen alle neben der Exe.

[EWeiss]

Zitat:

Zitat von DieDolly (Beitrag 1432149)

Ich versichere dir, das ist nicht das Problem ;)
Das Problem ist, dass der Provider nicht gefunden wird. Installieren möchte ich nichts um keine Abhängigkeiten zu erzeugen. Die SqlCE DLLs liegen alle neben der Exe.

Danke! Nur das konnte ich nicht riechen ;)

gruss

[Schokohase]

Zitat:

Zitat von DieDolly (Beitrag 1432149)

Das Problem ist, dass der Provider nicht gefunden wird. Installieren möchte ich nichts um keine Abhängigkeiten zu erzeugen. Die SqlCE DLLs liegen alle neben der Exe.

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.

Wenn du den OLEDB Provider nicht installieren möchtest, dann kannst du auch den Zugriff per OLEDB Provider vergessen und damit dbGo (also TAdoConnection)

[DieDolly]

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

[EWeiss]

Vielleicht hilft dir das etwas auf die Sprünge..

Zitat:

Wie macht es der SdfBrowser denn? Irgendwie muss das doch zu bewerkstelligen sein.

Wie ich schon sagte Delphi <> .net

PS:

Zitat:

Installieren möchte ich nichts um keine Abhängigkeiten zu erzeugen

Dann hast du auch keinen Provider.
Du kannst nicht auf die .net Runtime DLL's von Delphi aus zugreifen.
Du musst den Provider von MS installieren den du brauchst. Siehe!

gruss

[DieDolly]

Zitat:

To connecting ADO with SDF file,

Das muss nicht mit ADO sein. Der sdfBrowser kann es ja auch. Wie immer scheint es mal wieder nix für Delphi zu geben.

[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