locked
Aus der MSDN Hotline: Visual Fox Pro Datenbanken migrieren nach SQL Server RRS feed

  • Allgemeine Diskussion

  • Hallo zusammen,

    heute wurde uns bei der MSDN Hotline unter anderem folgende Frage gestellt: 
    Welche Möglichkeiten gibt es für eine Migration von Visual Fox Pro Datenbanken nach SQL Server?

    Unsere Antwort bzw. unser Lösungsvorschlag darauf war:
    Grundsätzlich gibt es 3 Möglichkeiten Fox Pro Datenbanken auf den SQL Server zu migrieren:

    Variante 1: Sie entwickeln eine .NET Anwendung und lesen in dieser die Fox Pro Datenbanken aus, und schreiben mittels eigener Anwendungslogik die Daten zum SQL Server. Diese Variante ist wahrscheinlich die aufwendigste aber natürlich auch die flexibelste.

    Die 2. Möglichkeit ist die Verwendung des „Upsizing Wizards“ in Visual Fox Pro. Dieser konvertiert Ihnen die Fox Pro Datenbanken. Die neueste Version des Upsizing Wizards können Sie unter [1] beziehen. Unter [2] gibt es eine ausführliche Beschreibung zum Wizard. Ferner findet man unter [3] noch Erfahrungsberichte und ein FAQ zum Upsizing Wizard.

    Ein dritter Weg führt über die SQL Server Integration Services (SSIS). Unter [4] gibt es einen ausführlichen Artikel zur Migration von Fox Pro Datenbanken nach SQL Server mittels SSIS. Relevant ist zudem auch das Whitepaper unter [5], dass Problemfelder der Migration von Fox Pro nach SQL Server detailliert bespricht.

    [1] http://vfpx.codeplex.com/releases/view/10224
    [2] http://msdn.microsoft.com/en-us/library/ecsk43h4%28v=vs.80%29.aspx
    [3] http://fox.wikis.com/wc.dll?Wiki~UpsizingWizard
    [4] http://www.craigbailey.net/vfp-importing-vfp-data-into-sql-server/
    [5] http://nationalcom.com/home/download/Conversion-VFP-SQLServer.pdf


    Wir hoffen, vielen Besuchern der MSDN Foren durch das Posten dieses Problems und einer möglichen Lösung weiterhelfen zu können.

    Viele Grüße,
    MSDN Hotline für MSDN Online Deutschland

    Disclaimer:
    Bitte haben Sie Verständnis dafür, dass wir hier auf Rückfragen gar nicht oder nur sehr zeitverzögert antworten können.
    Bitte nutzen Sie für Rückfragen oder neue Fragen den telefonischen Weg über die MSDN Hotline: http://www.msdn-online.de/Hotline 
    MSDN Hotline: Schnelle & kompetente Hilfe für Entwickler: kostenfrei!

    Es gelten für die MSDN Hotline und dieses Posting diese Nutzungsbedingungen, Hinweise zu Markenzeichen sowie die allgemein gültigen Informationen zur Datensicherheit sowie die gesonderten Nutzungsbedingungen für die MSDN Hotline.

    Freitag, 18. Februar 2011 16:30

Alle Antworten

  • Hallo,

    Wenn Sie von "grundsätzlich" sprechen, dann stimmt das schon aus der Sicht der beteiligten Komponenten, daß einmal VFP exportiert, einmal SQL Server importiert und einmal eine dritte Komponente - nach Ihrem Vorschlag .NET - zwischen beiden Seiten vermittelt.

    Wenn man Ihren 1. Lösungsvorschlag nimmt, also .NET sowohl die VFP Datenbank als auch SQL Server anbindet, dann muß man gar nicht mal unbedingt zu SQL-Server migrieren, wenn das Ziel eine .NET Applikation ist, hat man dann ja schon die Datenanbindung. Sobald seitens VFP massiv Stored Procedures involviert sind ist es sogar sinnvoll dort zu bleiben, denn sonst wird eine Neuimplementierung dieser Stored Procedures fällig. Auch abgesehen davon erscheint mir .NET als eine Migrationstool zu nutzen als der mühseligste Weg, auch der am wenigsten performante.

    Es gibt grundsätzlich noch die 4. Methode ähnlich zu Ihrer Variante 2 des VFP Upszing Wizards. VFP hat jedoch viel mehr und individuell wertvollere Methoden Daten aus VFP heraus zum SQL Server zu exportieren. Für jeden VFP Entwickler wird dieser Weg der natürlichste und flexibelste sein, weil er sich in VFP auskennt und man rein für die Datenmigration noch recht wenig SQL Server Wissen braucht. Man kann sich dafür z.B. aus dem quelloffenen in VFP geschriebenen Upsizing Wizard mit Wissen über z.B. Datenkonvertierungen, Datentypen etc. bedienen.

    Genausowenig, wie Sie für ihre Variante 1 eine allgemeine Lösungsmöglichkeit verlinken kann man das allerdings für diese Variante tun. Um dennoch kurz abrundend anzudeuten, wie man eine Tabelle im SQL Server mittels VFP  befüllen kann, hier die grundsätzlich Strategie aus VFP Sicht:

    Vorausgesetzt die leere SQL-Datenbank liegt vor, hat man ledigleich das gleiche zu tun, wie bei einer VFP Anwendung, die SQL Server als Datenbank Backend nutzt: Man bindet eine SQL Server Tabelle remote an, läßt dann nur eben einfach nicht einen User sondern Code Daten in diese Remoteanbindung einfüllen, sei die Remoteanbindung nun SQL Passthrough, Remote View oder Cursoradapter, das spielt keine Rolle. In jedem Fall hat man dann einen VFP Cursor und kann wie bei all diesen Remoteanbindungen üblich Änderungen per Einzeiler Tableupdate() senden, was in dem Fall dann eben nur eine komplette Tabellenfüllung ist, statt nur ein paar neue oder geänderte Einzeldatensätze. 

    Code benötigt das noch weniger als Worte:

    Local loTable1 as cursoradapter, lcAlias as String
    
    * per Cursoradapter die leere Tabelle einlesen in einen zur Remotequelle hin updatebaren VFP Cursor:
    loTable1 = CreateObject("caSQLTable1")
    * Die Tabelle wird nun VFP Seitig abgebildet unter dem Aliasnamen loTable1.Alias
    
    * Einfügen der Daten von DBF in diesen Adaptercursor
    Insert Into (loTable.Alias) Select * From VFPTable
    
    * Senden der Daten via Tableupdate()
    TableUpdate(.T.,.T.,loTable.Alias)

    Es wäre unfair zu erwähnen, daß die Vorarbeit nun natürlich im Erstellen der Remoteanbindung besteht, in diesem Fall einem Cursoradapter "caSQLTable1", der natürlich nicht vom Himmel fällt. Dazu gibt es einen guten Builder in VFP und ausführliche Anleitungen z.B. unter [6].

    Bei Remoteview wäre die Zeile mit dem Createobject("caSQLTable1") auszutauschen mit einem USE remoteview und im Tableupdate der Remoteview Aliasname anzugeben. Im Fall von SQL Passthrough läßt man einen Cursor mittels SQLExec erstellen und setzt per CursorSetProp die nötigen Eigenschaften zur Updatebarkeit - Keyfield, Updatable Fieldlist etc.

    Ein zweiter Teil Arbeit entsteht, wenn eine Umstrukturierung der Datenbank besteht und man mit dem einfachen SQL-INSERT INTO Cursor SELECT * FROM VFPTABLE nicht auskommt, sondern dort komplexere SQL-Abfragen benötigt, aber auch das gibt VFP SQL her. 

     

    Das ist sicherlich keine rein objektive Ergänzung zu Ihren Empfehlungen, dürfte aber auch dennoch interessant sein, um den geringen Migrationsaufwand, der innerhalb VFP besteht, zu sehen. VFP ist eben das beste Tool, um speziell auf DBFs und dann auch Remotedaten zuzugreifen.

    Sicherlich sind auch in einem SSIS Package pro Tabelle nur ein paar Clicks und Angaben pro zu befüllender Zieltabelle zu machen, ähnlich viel sind dann auch im Cursoradapter Builder oder Remoteviewdesigner nötig, aber es ist danach schon recht komfortabel in VFP mit einem Dreizeiler die SQL-Tabelle zu beschicken und dann bei Bedarf durch Strukturänderungen z.B. beliebige VFP Hilfsprozeduren Funktionen und Kommandos hinzufügen zu können, um die Daten auf das neue SQL Server Datenbankschema zu transformieren, speziell bei der 2. Zeile, dem SQL der DBF liest und in Remotecursor schreibt, kann natürlich auch xBase Code oder anderes eingesetzt werden, um den Ausgangspunkt DBF und Endpunkt Remotecursor zu verbinden.

    Last Not Least läßt sich diese Technik sehr wohl auch verwenden, um zwischen zwei Remotedatenbanken zu vermitteln. VFP ist über seine Anbindungsfähigkeit an Remotedaten sowohl per ODBC als auch per OLEDB neben .NET Sprachen ein guter Kandidat für Migrationsanwendungen oder auch Query und Reporting Tools.

    Mit freundlichen Grüßen.

    Tschüß, Olaf.

    [6] http://www.foxite.com/articles/read.aspx?id=49&document=creating-using-cursor-adapter-classes-a-simple-tutorial

    Sonntag, 20. Februar 2011 16:20