none
SQL Server CE Datenbank aus FoxPro-Tabellen erstellen RRS feed

  • Frage

  • Hallo,

    für Programme auf nem Pocket-PC benutze ich SQL Server Compact 3.5, das sowohl auf dem Desktop-System als auch auf dem Pocket-PC läuft.

    Ich will allerdings auf dem Desktop-PC die SDF-Dateien aus einer Sammlung freier DBFs erstellen. Provisorisch hab ich das erstmal gelöst über den Umweg per XML-Export aus FoxPro, deren Import in einem .NET-Programm und von dort aus daraus die SDF-Datei erzeugt.

    Ich möchte dass aber gerne direkt aus dem VFP-Programm heraus machen. Per ADO lässt sich der SQL Server Compact ansteuern, aber bislang hab ich sowas immer nur lesend gemacht. In diesem Fall müsste ich aber eine SQL-Datenbank überhaupt erstmal erzeugen und dann die Tabellen nach dem gleichen Schema wie die DBFs einfügen. Wie mache ich das?

    Gruß,

    Winfried

    Dienstag, 4. September 2012 17:43

Antworten

  • Erstelle einfach eine 0 Byte Datei mit Endung SDF und bilde den üblichen Connectionstring. Dann führe "CREATE DATABASE yourdb" aus und CREATE TABLE etc.

    Der etwas offiziellere Weg geht über ADOX.Catalog, mittels seiner Create() Methode wird die Datei, die Du im Connectionstring angibst darüber gleich mit Datenbank erzeugt.

    Tschüß, Olaf.



    • Als Antwort markiert WiWo Donnerstag, 6. September 2012 07:00
    • Bearbeitet Olaf Doschke Dienstag, 8. Januar 2013 17:39
    Mittwoch, 5. September 2012 10:14

Alle Antworten

  • Erstelle einfach eine 0 Byte Datei mit Endung SDF und bilde den üblichen Connectionstring. Dann führe "CREATE DATABASE yourdb" aus und CREATE TABLE etc.

    Der etwas offiziellere Weg geht über ADOX.Catalog, mittels seiner Create() Methode wird die Datei, die Du im Connectionstring angibst darüber gleich mit Datenbank erzeugt.

    Tschüß, Olaf.



    • Als Antwort markiert WiWo Donnerstag, 6. September 2012 07:00
    • Bearbeitet Olaf Doschke Dienstag, 8. Januar 2013 17:39
    Mittwoch, 5. September 2012 10:14
  • Hallo Olaf,

    inzwischen hab ich es schon mit ADOX hingekriegt. Ich hatte nur nirgends Beispielcode für VFP gesehen, dann aber in VB und das umgesetzt. Die Tabellenerstellung geht alternativ auch per ADOX.Table.

    Gruß,

    Winfried

    Mittwoch, 5. September 2012 10:52
  • Hallo,

    ich habe das selbe Problem, mache aber in FoxPro aber nur noch recht wenig.

    Deshalb zwei Fragen:

    1. Was ist der "üblichen Connectionstring" ?

    2. Kann ich den VB Code haben ?

    Danke im voraus

    Peter

    Sonntag, 6. Januar 2013 10:47
  • >Erstelle einfach eine 0 Byte Datei mit Endung SDF und bilde den üblichen Connectionstring.

    Ausführlicher:

    1. Erstelle einfach eine 0 Byte Datei mit Endung SDF

    z.B. Einfach neue Textdatei erstellen und die Dateiendung in SDF umbenennen.

    Doppelklicke die Datei, ein Dialog zum erstellen einer Connection führt Dich nun. Wenn Du fertig bist, findest Du den connectionstring innerhalb der SDF Datei, am einfachsten kommt man daran, wenn man die Dateiendung wieder in TXT abändert.

    Den Connectionstring kannst Du dann für VFP Cursoradapter im ADO modus oder ADODB.Connections verwenden, wie üblich.

    Tschüß, Olaf.

    Montag, 7. Januar 2013 10:12
  • Was für ein Programm muß denn auf dem Rechner installiert sein, damit die Sache mit dem Doppelklick eingeleitet wird ?

    Danke

    Montag, 7. Januar 2013 14:09
  • Hallo Peter,

    Sorry, vergiss was ich sagte, ich habe da zwei Sachen zusammengemanscht, die nicht zusammengehören.

    1. Die SDF Datei soll einfach die neue SQL Server Compact Datenbank werden, mit der Datei machst Du nichts, keinen Doppelklick.

    Um einen Connectionstring zu kriegen kannst Du das beschriebene Prozedere machen mit einer weiteren Datei, deren Endung Du in UDL abänderst, nicht in SDF. Ab da geht es dann mit dem Doppelklick.

    Du brauchst kein Programm dafür, aber SQL Compact sollte einen OLEDB Provider mit installieren, den Du auf dem Reiter Provider dann wählen kannst. Wenn nicht, dann findest Du bestimmt unter

    http://www.connectionstrings.com/sql-server-ce#microsoft-sqlserver-ce-oledb-3-5

    den passenden Connectionstring.

    Tschüß, Olaf.


    Dienstag, 8. Januar 2013 17:37
  • Nun steht in der Datei etwas.
    Muß mich aber wohl für die weiteren Dinge etwas näher damit beschäftigen.

    Ich werde es Dir im nächsten Leben vergelten, bis dahin erstmal besten Dank

    Mittwoch, 9. Januar 2013 21:17
  • Hallo,
    unter dem Link findet man nichts mehr, ich habe aber das gefunden:

    microsoft.com/sqlserver/en/us/editions/2012-editions/compact.aspx

    Nach der Installation erhalte ich nun aber eine Fehlermeldung:
    D:datei.udl: Die Datei kann nicht geöffnet werden. Stellen Sie sicher,
    dass es sich um eine gültige Datenverknüpfungsdatei handelt

    Ist die Endung UDL nicht mehr korrekt ?

    Donnerstag, 10. Januar 2013 10:18
  • Hallo Peter,

    .UDL ist bei mir verknüpft mit:

    Rundll32.exe "%CommonProgramFiles%\System\OLE DB\oledb32.dll",OpenDSLFile %1   

    und funktioniert mit ner leeren Datei, aber nicht mit einer, die unpassendes enthält.

    Das Fenster "Dateiverknüpfungseigenschaften", was nach Click auf eine leere .UDL erscheint, listet allerlei OLE DB Provider, auch die von VFP und vom SQL-Server, aber bei mir nicht die des SQL-Servers CE. Aber aus VFP ist der trotzdem ansprechbar.

    Gruß,

    Winfried


    • Bearbeitet WiWo Donnerstag, 10. Januar 2013 11:05
    Donnerstag, 10. Januar 2013 11:04
  • Merkwürdig.

    Wenn ich dem Dateityp UDL "OLE DB Core Services"  dann erhalte ich die Fehlermeldung. Weise ich UDL ein anderes Programm zu, verschwindet der Eintrag "OLE..." und ich erhalte "Unbekannte Anwendung" Und dann passiert nichts mehr, wenn ich auf UDL Doppelklicke.

    Donnerstag, 10. Januar 2013 12:03
  • >Ich werde es Dir im nächsten Leben vergelten, bis dahin erstmal besten Dank

    Diesen Aphorismus kannte ich so noch nicht, gefällt mir.

    Der Link zu Connectionstrings.com funktioniert für mich nach wie vor, der war und ist frisch, wenn immer noch nicht, hangel Dich doch von http://www.connectionstrings.com aus durch.

    Was Winfried mittlerweile sagte stimmt allerdings auch, die ein zwei CE Provider, die es gibt, werden in dem OLEDB Connection Manager - wie ich das jetzt einfach mal nenne - nicht aufgelistet.

    Sorry, auch dafür. Eine weitere Sackgasse. Für andere DBs ist der Trick mit der UDL Datei allerdings schon ganz nett.

    Die Datei soll allerdings nur der visuellen Erstellung des Connectionstrings dienen, nicht als der Connectiostring, d.h. man zieht aus dem Text den Teil raus, den man für seinen Connectioncode braucht.

    Also nehemen wir doch einfach mal den Connectionstring für den nicht aufgelisteten Provider "Microsoft.SQLSERVER.CE.OLEDB.3.5". Der dürfte nach Installation von SQL Server CE trotzdem vorhanden sein. Folgernder Dreizeiler verbindet dann zu einer SDF Datenbank, die bereits existiert:

    o = CreateObject("adodb.connection")
    o.ConnectionString = "Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=D:\temp\Data.sdf;"
    o.Open()

    Damit bis Du dann auf dem Stand, auf dem Winfried war, als er die ursprüngliche Frage gestellt hat.

    Aber wie erzeugt man eine SDF, wenn noch keine da ist?

    Und da kann man eben einfach eine leere Datei erstellen und die Endung auf SDF ändern, der erste Connect zu der 0-Byte Datei macht dann eine SDF Datenbank daraus.

    Nun ist noch unklar, was Dir noch fehlt, was Du eigentlich brauchst, Deine Einstiegsfrage ging ja eher an Winfried, ob Du seinen Code haben kannst.

    Und was ich mit ADOX.Catalog angerissen habe ginge im Detail so:

    o = CreateObject("adox.catalog")
    o.Create("Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=D:\temp\Data2.sdf;")

    Das geht auch, wenn die SDF-Datei (in dem Fall als Data2.sdf) noch nicht existiert. Insofern ist das weniger Trickreich und insofern wohl eher der offiziellere Weg, eine SDF ohne tricksen zu erzeugen.

    Tschüß, Olaf.


    Nachtrag: Da Du über Deinen aktuellen Produkt-Link zum Download von SQL Server® Compact 4.0 SP1 kommst, dürfte der Provider dann auch Microsoft.SQLSERVER.CE.OLEDB.4.0 heißen, ich hab meine CE Installation jetzt nicht aktualisiert.

    Donnerstag, 10. Januar 2013 12:08
  • Ich habe eine VFP Anwendung. Für dieses Programm gibt es eine mobile Datenerfassung unter WinCE.

    Den kleinen Rechner muß man zu Beginn mit Daten laden. Das mache ich mit Textdateien. Erkennt der kleine die Dateien, speichert er die Daten seine Datenbanktabellen.
    Dieser Weg ist der Tatsache geschuldet, daß es das mobile Programm vor vielen Jahren bereits auf einem Psion gegeben hat.

    Dieser Weg dauert zu lange. Die kleinen Rechner sind einfach zu langsam. Auf dem PC ist das nur ein Wimperschlag, so daß ich die Daten auf Dauer gerne bereits auf dem PC so erzeugen möchte, daß der PPC damit sofort loslegen kann.

    Und auf den Psion muß ich inzwischen keine Rücksicht mehr nehmen.

    Ich werde das mal ausprobieren.

    Donnerstag, 10. Januar 2013 12:52
  • Damit es keine Abmahnung gibt: Der Aphorismus ist nicht von mir, sondern aus "Tadellöser & Sohn". Urheber ist vermutlich Walter Kempowski
    Donnerstag, 10. Januar 2013 12:54
  • Nun habe ich der Version 3.5 gefunden und auch installiert.

    Beim "open" Befehl gibt es folgenden Fehler

    1429, OLE-IDispatch-Ausnahmecode 0 von Provider: Schwerwiegender Fehler..    

    Nun bin ich doch ziemlich ratlos. Ich nutze das unter Windows 8.     

    Donnerstag, 10. Januar 2013 14:54
  • Hallo Peter,

    soweit ich weiss, läuft Version 4 sowieso nicht auf nem CE-Gerät und die Datenbank-Dateien sind auch nicht kompatibel.

    Ich hab das hier mit ähnlicher Aufgabenstellung mit Vers. 3.5 aufgebaut, also .SDF-Datenbank per VFP-Programm erzeugt, per RAPI-calls zum Pocket-Terminal rübergeschoben und dort damit gearbeitet.

    Leider hat dann der Auftraggeber das so nicht haben wollen und stattdessen seinen schon verhandenen Export von XML-Dateien beibehalten, was das Ganze grauenhaft verlangsamt.

    Für ein anderes Projekt werd ich das demnächst aber wieder direkt mit .SDF-Dateien machen und den alten Versuchscode wieder ausgraben.

    Gruß,

    Winfried

    Donnerstag, 10. Januar 2013 15:38
  • Hallo Winfried,

    die Version 3.5 habe ich ja nun auch installiert, trotzdem tritt ein Fehler auf.

    So wie Du das beschrieben hast, habe ich das auch gemacht, nur eben mit Textdateien.
    Und das ist einfach zu langsam. Das Programm gab es auch unter embeddedVB, da war
    das noch zu ertragen.

    Danke im voraus

    Peter

    Donnerstag, 10. Januar 2013 15:56
  • Welche der beiden Varianten hast Du denn jetzt genommen? Bei der ersten muß eine SDF Datei bestehen, sonst gibt es beim Open Versuch tatsächlich den Fehler.

    Die SDF kann eine bestehende DB sein, aber auch eine leere Datei, die dann automatisch zu einer vollwertigen SDF Datenbank wird, ca. 20KB, aber immer noch leer, ohne irgendeine Tabelle.

    Ab da geht es dann weiter per ADODB.Connection kann man ja SQL ausführen, auch CREATE TABLE, etc.

    Tschüß, Olaf.

    Donnerstag, 10. Januar 2013 23:46
  • Ich habe die Version 3.5 verwendet. Zuerst die Version X86, dann die 64Bit Version installiert. Dazu gab es einen Hinweis.

    Inzwischen ist die Datei mit einem Icon verknüpft, eine "gelbe Tonne rechts daneben so etwas wie eine Tabelle". Es ist zum Mäusemelken.

    Freitag, 11. Januar 2013 06:36
  • Ich habe das nun auch unter Windows 7 geprüft, das selbe Ergebnis. Ich kann von beiden Betriebssystempartitionen auf den selben Datenbestand zugreifen, Verwechslung ist ausgeschlossen.

    Was ich nicht verstehe ist, daß es mir nicht mehr gelingt, die vorhandenen Provider mit einem Doppelklick auf die UDL-Datei anzuzeigen. Das hat ja zwischenzeitlich funktioniert.

    Freitag, 11. Januar 2013 08:53
  • Halleluja,

    ich weiß zwar nicht wieso, aber plötzlich funktioniert es auch bei mir :-)

    Samstag, 12. Januar 2013 13:22
  • >plötzlich funktioniert es auch bei mir

    Ich frag jetzt gar nicht, warum. Das wirst Du kaum mehr sagen können.

    Nur eins: 64Bit Treiber kann VFP nun wirklich gar nicht nutzen, nicht einmal "sehen". Sollte also z.b. ein ODBC Treiber nur als 64Bit Version existieren und in einer 64Bit Anwendung mit bestimmtem Connectionstring funktionieren, dann wird derselbe Connectionstring in VFP nicht funktionieren. 

    Die 64bit Treiber für SQL Server, auch die für den Compact Server, sind aber immer entweder nur 32bit für 32bit Systeme oder im Setup sind beide Varianten drin. Noch gibt es keine einzige Windows 64bit Version, die kein 32bit Subsystem hat und MS unterstützt auch immer noch die 32bit Windows Varianten, auch wenn es keine neuen 32bit CPUs mehr gibt.

    Die denkbare Vaiante von reinen 64bit Treibern/Providern ist bislang soweit ich weiß noch keine Realität.

    Wichtig zu merken an dem ganzen ist, nicht die Windows Variante, sondern die Applikation bestimmt, was man braucht. Und VFP ist und bleibt eine 32bit Applikation, die auch nur 32bit Applikationen erstellt.

    Tschüß, Olaf.

    Samstag, 12. Januar 2013 21:59
  • Hallo,
    nein, das weiß ich nicht. Vermutlich habe ich einen stümperhaften Fehler gemacht, dann fängt man an, ohne Verstand herumzufummeln.

    Die Sache mit den 32/64Bit habe ich nur geschrieben, weil in dem Paket folgender Text steht:

    ---------------------------------------------------------------------------------------------------------------

    Installieren Sie sowohl die 32-Bit- als auch die 64-Bit-Version von Microsoft SQL Server Compact 3.5 Service Pack 2 auf einem 64-Bit-Computer.
    ----------------------------------------------------------------------------------------------------------------------------------------------
    Microsoft SQL Server Compact 3.5 Service Pack 2 verfügt über separate Windows Installer (MSI)-Dateien für Computer mit 32-Bit (x86)
    und 64-Bit (x64 oder AMD64). Auf einem 64-Bit-Computer muss sowohl die 32-Bit- als auch die 64-Bit-Version der MSI-Datei von SQL Server
    Compact installiert werden. Wenn Sie nur die 32-Bit-Version der MSI-Datei von SQL Server Compact 3.5 SP2 auf einem 64-Bit-Computer
    installieren, verursacht dies einen Fehler bei den vorhandenen SQL Server Compact 3.5-Anwendungen auf dem Computer. Wenn Sie eine
    Anwendung entwickeln, die SQL Server Compact 3.5 SP2 verwendet, sollten Sie sowohl die 32-Bit- als auch die 64-Bit-Version der MSI-Datei
    von SQL Server Compact in das Paket aufnehmen und beide zusammen mit der Anwendung auf einem 64-Bit-Computer installieren.

    Damit alle Anwendungen, die von SQL Server Compact 3.5 SP2 abhängig sind, ordnungsgemäß auf dem Computer funktionieren, installieren
    Sie SQL Server Compact 3.5 SP2 wie folgt:

    Installieren von SQL Server Compact 3.5 SP2 auf einem 32-Bit-Computer (x86):
    1. Installieren Sie die 32-Bit-Version von SQL Server Compact 3.5 SP2, indem Sie die Datei "SSCERuntime-DEU-x86.msi" ausführen.

    Installieren von SQL Server Compact 3.5 SP2 auf einem 64-Bit-Computer (x64 oder AMD64):
    1. Installieren Sie die 32-Bit-Version von SQL Server Compact 3.5 SP2, indem Sie die Datei "SSCERuntime-DEU-x86.msi" ausführen.
    2. Installieren Sie dann die 64-Bit-Version von SQL Server Compact 3.5 SP2, indem Sie die Datei "SSCERuntime-DEU-x64.msi" ausführen.

    Sonntag, 13. Januar 2013 10:19
  • Installieren von SQL Server Compact 3.5 SP2 auf einem 64-Bit-Computer (x64 oder AMD64):
    1. Installieren Sie die 32-Bit-Version von SQL Server Compact 3.5 SP2, indem Sie die Datei "SSCERuntime-DEU-x86.msi" ausführen.
    2. Installieren Sie dann die 64-Bit-Version von SQL Server Compact 3.5 SP2, indem Sie die Datei "SSCERuntime-DEU-x64.msi" ausführen.

    OK, dann wird das so seine Richtigkeit haben, die normalen SQL Server Varianten installiert man jedenfalls nicht so einzeln. Allerdings installiert man ab SS2008R2 sowieso nur noch ein Installationscenter, mit dem man dann die eigentliche Installation vorbereitet und ausführt.

    SQL2005 installierte man zumindest noch nur die 64bit Version und die installierte 32bit Treiber gleich mit.

    Die Compact Version ist ja schon noch was anderes. Ist schon ewig her, daß ich SQL Compact installiert habe, auf Win7 64bit allerdings. Ich erinnere mich nicht, zwei Installationen gemacht zu haben.

    Tschüß, Olaf.

    Sonntag, 13. Januar 2013 17:59
  • Nun habe ich das soweit am laufen, aber bei den weiteren Arbeiten beiße ich mich immer wieder fest. Ich habe etwas Beispielcode gefunden, der in VB geschrieben ist. Aber beim Portierten mache ich immer wieder neue Fehler.

    Hat jemand Beispielcode, wie ich eine Tabelle erzeuge und diese mit Daten fülle. Mehr brauche ich für meine Sache nicht.

    Danke im voraus

    Sonntag, 27. Januar 2013 11:38
  • Was bedeutet denn "soweit am laufen", wenn Du nicht einmal eine Tabelle erstellt hast? Weniger geht ja kaum. 

    Wenn eine SDF-Datei besteht, dann kannst Du eine Tabelle erstellen per:

    oAdoConn = CreateObject("adodb.connection")
    oAdoConn.ConnectionString = "Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=C:\data\my.sdf;"
    oAdoConn.open()

    oAdoConn.Execute("Create Table yourTable (id int, cText char(20))")

    und darin einen Datensatz anlegen per

    oAdoConn.Execute("Insert Into yourtble (id,cText) Values (1,'hello, world')")

    Tschüß, Olaf.



    Sonntag, 27. Januar 2013 21:25
  • Danke, werde es mal testen
    Montag, 28. Januar 2013 03:58
  • Mit "Soweit" meinte ich das Erzeugen der Datei.

    Nun macht aber dieser Befehl bei mir mucken:

    oAdoConn.Execute("Create Table Kunden(id int, cText char(20))")

    OLE-IDispatch-Ausnahmecode 0 von Microsoft SQL Server Compact OLE DB Provider. Der Befehl
    enthält mindestens einen Fehler

    Montag, 28. Januar 2013 15:16
  • Du nimmst das zu wortwörtlich. CE unterstützt nicht dieselben Feldtypen wie der normale SQL Server. Eine Referenz hilft da. Schau z.B. http://www.der-softwareentwickler-blog.de/2008/11/05/aufpassen-bei-sql-server-compact-edition-datentypen/

    Oder halt die offizielle Referenz: http://msdn.microsoft.com/en-us/library/ms172424(v=sql.100).aspx

    Unmissverständlich gesagt: SQL CE kennt nicht einmal char, dafür aber nchar.

    Und sorry dafür zu faul zu sein gleich ein funktionierendes Beispiel zu geben. Ich weiss aber sowieso nicht, welche Tabellen Du brauchst, das mußt Du Dir sowieso nicht nur namentlich selbst zusammensuchen, Du wirst ja sicherlich mehr als nur integer und char Felder füllen wollen. Mir ging es nur ums Execute als um Create Table.

    Tschüß, Olaf.

    Montag, 28. Januar 2013 19:31
  • Danke, nun habe ich es. Mit smallint und ntext geht es :-)

    Montag, 28. Januar 2013 19:46
  • Alles klar, dann viel Erfolg und Spaß damit.

    Integer gibt es auch, als integer, das entspricht dann genau dem Foxpro Wertebereich von 32 Bit Integern. Aber VFP wird sich ein smallint wahrschelich sowieso als integer abholen.

    Tschüß, Olaf.


    Mittwoch, 30. Januar 2013 17:21
  • Gibt es eigentlich eine Möglichkeit, irgendein Tool usw., mit dem man sich die vorhandenen Datenbankprovider des PCs anzeigen lassen kann ?

    Das Problem was ich habe ist, dass die Zielmaschine - ein HTC Smartphone - einfach keine Datenbank der Version 3.5 mag. Ich habe das Gerät völlig platt gemacht, dann Treiber für 3.5 ohne Mucken installiert, arbeiten will der Kleine aber nur mit der Version 3.1.

    Der folgende Befehl funktioniert auf meinem PC:

    oConn.ConnectionString = "Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=d:\DataSQL.sdf;"

    Dieser Befehl allerdings nicht

    oConn.ConnectionString = "Provider=Microsoft.SQLSERVER.CE.OLEDB.3.1;Data Source=d:\DataSQL.sdf;"

    Bei MS habe ich die Datei SQLServerCE31-DE.msi gefunden. So wie ich das verstanden habe, müßte nun auch die Version 3.1 zur Verfügung stehen. Damit funktioniert es aber nicht.

    Mittwoch, 30. Januar 2013 17:39