Foxpro Frontend SQLExpress Backend?

[marc9022]

Hallo liebe Leute,

Ich habe folgende Ausgangssituation.

1. Alte Foxpro 6.0 Anwendung mit nativer Win32 Start.exe
2. Backend ist selbst in Foxpro Tabellen realisiert.

Wie schwer wäre es, das Frontend in Foxpro zu belassen und
das Backend auf MS-SQL-Express zu portieren?

Es geht darum, das wir nicht mehr genug Speicherplatz in der Datenbank
haben.

Später (bei einem reWrite) soll die ganze Applikation als WebApplikation
realisiert werden, die nach bisheriger Planung in ASP.NET mittels
c# realisiert werden soll.Davor graut mir allerdings, weil der Chef auch eine
offline Version will, die der Kunde als normales Setup per CD bekommen und
ohne Installation auf dem Rechner betreiben soll können (also start from USB-Stick). Er erhofft sich dadurch wesentlich weniger Supportanfragen.

[Bernhard Geyer]

Du weist schon das Foxpro gestorben ist. Bevor du jetzt einen großen Aufwand in die Trennung mit MS SQL-Server als Backend investierst so redesign gleich komplett die Anwendung.

[robert.oh.]

Hallo,
als erstes, VFP ist nicht gestorben, der Support von MS wird lediglich 2015 eingestellt. Die Community ist aber weiterhin riesengross und es gibt auch schon Geruechte ueber moegliche 'neue Eltern'.

Eine VFP Applikation mit einem SQL Server Backend zu versehen kann einfach, aber auch ziemlich kompliziert sein.

Freie Tabellen:
Am einfachsten waere es, wenn ihr in der derzeitigen VFP App. nur freie Tabellen verwenden wuerdet, denn somit koennte man einfach beim Programmstart die Tabellen vom SQL laden (zB mit SQLStringConnect oder TableAdapter [n/a in VFP6]) und weiterhin mit lokalen Cursor arbeiten. Eingegriffen werden muesste nur beim Laden und Zurueckschreiben (Insert, Update, Delete) der Daten.

DBC:
Wenn ihr jedoch in der VFP App mit den VFP DataBase Containern (DBC) arbeitet, wird die Sache schon wieder ein bisschen kniffliger. Das Laden und Zurueckschreiben der Daten wuerde sich gleich wie im obigen Fall verhalten, aber wenn ihr zusaetzlich im DBC noch mit Relationen, Indizes, Triggern, ... arbeitet, dann muessen diese nach dem Laden der Daten vom SQL manuell gesetzt werden.

DataEnvironment:
Wenn ihr bei den Forms mit DE arbeitet und dort die benoetigten Tabellen ladet, braucht ihr nur in der 'BeforeOpenTables'-Methode (oder so aehnlich) des DE die benoetigten Tabellen laden und den Code fuer das Zueruckschreiben umbauen - fertig.

SQLExpress hat eine Limitierung pro Datenbank von 4 GB - ich wollte es nur mal anmerken.

Wenn ihr die Daten von DBF nach SQL transformiert / speichert und ihr in der SQL DB einige VARCHAR(...) Felder habt, wuerde ich gelegentlich ein SQL Skript ueber die DB laufen lassen, welches einen RTRIM(...) auf die VARCHAR-Felder absetzt. VFP speichert naemlich ueber ODBC immer die volle Zeichenlaenge!
So kann es vorkommen, dass ein VARCHAR(200) Feld im SQL nur 3 effektive Zeichen enthaelt, aber trotzdem durch den ODBC Treiber mit 197 Leerzeichen aufgefuellt worden ist.

Wenn ihr professionelle Hilfe benoetigt koennen wir von EPS (Amerika oder Austria, www.vfpconversion.de ) euch sicher weiterhelfen - ist nicht als Werbung gedacht, sondern nur als Hilfestellung!

Viel Spass beim Konvertieren?

[marc9022]

Hallo,
als erstes, VFP ist nicht gestorben, der Support von MS wird lediglich 2015 eingestellt. Die Community ist aber weiterhin riesengross und es gibt auch schon Geruechte ueber moegliche 'neue Eltern'.

Das habe ich mir auch schon gedacht.
Wir haben halt den IstZustand das wir ein externes Softwarehaus
damit beauftragt haben unsere derzeitige Endkundensoftware zu
pflegen. Sie sind sehr gut, kennen sich im Krankenversicherungs Bereich
bestens aus und die Kommunikation zwischen Ihnen und uns läuft
ohne Dramen und auf Augenhöhe. Das wollen wir uns natürlich bewahren.

In Foxpro sind sie gut, aber von allem andern verstehen sie nicht so viel
und eine Migration auf Foxpro 9.0 SP2 trauen sie sich nicht zu.
Da haben sie mal die Aussage getroffen, das man an zu viele
Stellen "ran" müsste und es sich nicht lohnen würde.

Ich bin da anderer Meinung und zwar deshalb weil dort einige
Fremdkomponenten (Delphi DLL's und ActiveX Komponenten) verbaut sind,
von denen wir teilweise nicht mal den Sourcecode haben. und auch nicht mehr auftreiben können (schon alles versucht).

Was wir haben ist unser Foxpro 6.0 Hauptprogramm, die Tabellen sind als
DBF ausgelegt und eben einige Blackboxkomponenten die mit Delphi
gebastelt wurden. Die Blackboxen können wir sicher irgendwann abschaffen,
aber das komplette Programm neu zu schreiben ist einfach zu viel und davor hat hier jeder Angst (wir sind Migrationsgeschädigt und schon ziemlich übel von diversen Programmierern hinter die Fichte geführt worden).


Nach meiner Einschätzung wäre es halt ein Risen Plus, wenn wir
auf 9.0 SP2 upgraden und die Foxpro Datenbank gegen MS-SQL
oder eine gute andere DB austauschen könnten. Damit würden
wir noch jahrelang gut zurechtkommen und in aller Gemütsruhe
eine neue Anwendung nebenher, ohne Zeitdruck programmieren.

SQLExpress hat eine Limitierung pro Datenbank von 4 GB - ich wollte es nur mal anmerken.

Sind jetzt glaube ich sogar 5 GByte, sollte aber unseren Rahmen noch nicht sprengen.

Wenn ihr die Daten von DBF nach SQL transformiert / speichert und ihr in der SQL DB einige VARCHAR(...) Felder habt, wuerde ich gelegentlich ein SQL Skript ueber die DB laufen lassen, welches einen RTRIM(...) auf die VARCHAR-Felder absetzt. VFP speichert naemlich ueber ODBC immer die volle Zeichenlaenge!
So kann es vorkommen, dass ein VARCHAR(200) Feld im SQL nur 3 effektive Zeichen enthaelt, aber trotzdem durch den ODBC Treiber mit 197 Leerzeichen aufgefuellt worden ist.

Also ich weiß ja nicht ob ODBC für den Zugriff auf DBF's erforderlich ist,
aber wenn das möglich ist, dann liebend gerne! ODBC ist Teufelszeug!

Wenn ihr professionelle Hilfe benoetigt koennen wir von EPS (Amerika oder Austria, www.vfpconversion.de ) euch sicher weiterhelfen - ist nicht als Werbung gedacht, sondern nur als Hilfestellung!

Viel Spass beim Konvertieren?

Naja, da haben wir langfristig was anderes vor. Wir wollen unsere
Branchenlösung als WebApplikation aufbauen, der Chef will das es ASP.NET ist aber dagegen streubt es mich sehr, weil die Kontrolle über die Eingaben
in WinForms oder native Win32 Fenstern doch noch besser geregelt werden
kann. Bei BrowserApps kommt man schnell an bestimmte Grenzen. Da kann man gar nicht oft genug die Validität der Daten überprüfen (Popup-Blocker, PhishingFilter, Antivirus Programme, Zoneneinstellungen, JavaScript (an/aus),
CSS2 wird nciht vollständig untersützt u.s.w.

Wenn, dann würde ich wohl JavaFX für das Frontend nutzen wollen oder
Flash. Da läuft es dann entweder oder eben nicht. Zumindest nicht nur ein "bißchen".

[marc9022]

Du weist schon das Foxpro gestorben ist. Bevor du jetzt einen großen Aufwand in die Trennung mit MS SQL-Server als Backend investierst so redesign gleich komplett die Anwendung.

Aufwand ist genau das richtige Stichwort.

Die Anwendung so wie sie läuft ist ok, Nur die DB die hinten dranhängt ist
einfach am Limit. Langfristig haben wir eh etwas anderes mit einer neuen
Applikation vor, aber bis dahin pflegen wir natürlich unsere Cashcow die seit jahren gut beim Kunden läuft.

[robert.oh.]

Hallo,

Also ich weiß ja nicht ob ODBC für den Zugriff auf DBF's erforderlich ist,
aber wenn das möglich ist, dann liebend gerne! ODBC ist Teufelszeug!

VFP verwendet im Hintergrund standardmaessig ODBC fuer den Zugriff auf eine SQL Datenbank und macht das auch alles recht problemlos - ist wirklich zuverlaessig und einfach in der Handhabung.

Naja, da haben wir langfristig was anderes vor. Wir wollen unsere
Branchenlösung als WebApplikation aufbauen, der Chef will das es ASP.NET ist aber dagegen streubt es mich sehr, weil die Kontrolle über die Eingaben
in WinForms oder native Win32 Fenstern doch noch besser geregelt werden
kann. Bei BrowserApps kommt man schnell an bestimmte Grenzen. Da kann man gar nicht oft genug die Validität der Daten überprüfen (Popup-Blocker, PhishingFilter, Antivirus Programme, Zoneneinstellungen, JavaScript (an/aus),
CSS2 wird nciht vollständig untersützt u.s.w.

Wenn, dann würde ich wohl JavaFX für das Frontend nutzen wollen oder
Flash. Da läuft es dann entweder oder eben nicht. Zumindest nicht nur ein "bißchen".

Also mit Flash wuerde ich keine - wie mir scheint - doch recht komplexe Applikation schreiben.
In diesem Zusammenhang waere vielleicht ClickOnce, WCF oder sogar vielleicht Silverlight eine Ueberlegung Wert.

Der Vorteil von ClickOnce waere, dass du die kompletten WinForms Funktionen und Komfort hast und noch dazu einen eleganten Mechanismus der Verteilung ueber das Web.

[marc9022]

Hallo,

VFP verwendet im Hintergrund standardmaessig ODBC fuer den Zugriff auf eine SQL Datenbank und macht das auch alles recht problemlos - ist wirklich zuverlaessig und einfach in der Handhabung.

Mit ODBC habe ich in 15 Jahren Softwareentwicklung die seltsamsten
Sachen erlebt ;d hab sogar selber mal einen ODBC Treiber entwickelt
und muss sagen das mir gar nicht gefällt was ich dabei herrausgefunden habe ;D

Also mit Flash wuerde ich keine - wie mir scheint - doch recht komplexe Applikation schreiben.
In diesem Zusammenhang waere vielleicht ClickOnce, WCF oder sogar vielleicht Silverlight eine Ueberlegung Wert.

Der Vorteil von ClickOnce waere, dass du die kompletten WinForms Funktionen und Komfort hast und noch dazu einen eleganten Mechanismus der Verteilung ueber das Web.

Naja, es ist schon ein mehrschichtiges System das da im Anmarsch ist.
Ich bin ganz ehrlich, ich halte nicht viel von Microsoft Entwicklungstools. Vieles
ist nur Eycandy und die meisten Produkte sind völlig überdimensioniert und 99%
der Funktionalität wird nicht benötigt. Die Doku im MSDN ist Grauenvoll und die
tollen Wizards die einem eigentlich helfen sollen machen oftmals mehr Murks als
alles andere (besonders wenn sie automatischen Code erzeugen sollen, der
von Menschen verstanden und gewartet werden soll).

Ich kodiere meinen Code selber. Wenn ein Projekte nicht komplett in ein Zipachiv
passt, kompiliert und sofort gestartet werden kann, habe ich etwas falsch gemacht.
Nie und Nimmer werde ich als Entwickler den Microsoft Gigantismus mitmachen oder
auch nur in Erwähnung ziehen damit zu arbeiten. Sogar ASP.NET c# Seiten
liegen bei mir nur im Quellcode vor und ich verwende kein Codebehind oder
Visual Designer oder HTML-Controls. Was das mit deiner WebApplikation
anstellen kann, sieht man auf diversen Websites die träger und lahmer nicht
sein können. Debugge mal so ein doofes Datagrid wo Du keine Kontrolle
über den Source hast...

Ausserdem habe ich als WebApplikationsplatform nicht nur Windows zur
verfügung, davon halte ich als Unix Mensch sowieso recht wenig. Das fängt damit an,
das man die Kiste beim patchen oft neustarten muss, das Patches einspielen auf
Produktivsystemen unter Windows immer noch ein unberechenbares Abtenteuer
ist und hört damit auf, das es dann an irgendeiner Stelle heißt. "Wenn Sie dieses Feature
verwenden wollen, zahlen sie bitte 33.000 EUR"!

Das kann ich einem Chef nicht vermitteln, sowas kann das aus für ein Projekt das aus
bedeuten, also verschaffe ich mir Spielräume und schone meine Investitionen, so dass
ich sie dort ausgeben kann wo sie wirklich gebraucht werden (z.B in neue Hardware
statt Lizenzen für irgend eine MS Enterprise 2008xx Edition).

Meine derzeitige FreeBSD Maschine läuft 533 Tage ohne Neustart und
ist auf dem neuesten Patchstand und darauf laufen J2EE Enterprise Applikationen mit
hohen Usertraffic.

ps: Flasch oder JavaFX bieten gute möglichkeiten um ein Frontend zu gestalten und
kleinere Validitätschecks in den Formularfeldern zu realisieren und daher einen besseren
Ausgabelayer als HTML ohne den Server zusätzlich zu belasten.

[robert.oh.]

Hallo,

Danke fuer die interessante Ausfuehrung.
Ich will jetzt keine Grundsatzdiskussion ueber MS oder Java, Win oder Unix starten - ich bin einfach mal ein Windows / MS Mensch und - gleich wie bei jedem anderen System oder Tool - man lernt damit umzugehen und weiss wo man aufpassen muss

Hauptsache das Ergebnis stimmt und der Kunde ist zufrieden

[marc9022]

Hallo,

Danke fuer die interessante Ausfuehrung.
Ich will jetzt keine Grundsatzdiskussion ueber MS oder Java, Win oder Unix starten - ich bin einfach mal ein Windows / MS Mensch und - gleich wie bei jedem anderen System oder Tool - man lernt damit umzugehen und weiss wo man aufpassen muss

Hauptsache das Ergebnis stimmt und der Kunde ist zufrieden

Hast schon recht. Der Endkunde im Desktopbereich erwartet meist auch Windows oder in seltenen Fällen Mac. Linux und Unix kommt doch, wenn man mal ehrlich ist nur im Server und Adminbereich zum Einsatz und das ist wiederum nicht das was der Endanweder braucht.

Ich habe halt lange unter Win32 Software entwickelt und mir gings immer tierisch gegen den Strich wenn durch die Nutzung einer coolen Komponente
gleich beim Kunden ein völlig neues OS aufgespielt werden musste.
(wenn man Glück hatte, nur bei einem Rechner und wenn man Pech hatte bei
bei hunderten).

Und dann diese Abschottung. Gerade wieder sitze ich in der MSDN Bibliothek und recherchiere eine Win32-Funktion, wo mal wieder nicht alles dokumentiert ist. Letztendlich muss ich sie wohl anrufen und so lange dumme Fragen stellen bis ich die richtigen Antworten höre.

Und das stimmt jetzt wirklich... unter Linux ist mir das noch nie passiert ;D

Alle Programme sind Vollversionen und offen, wenn ich einen Spezialisten
brauche der was anpassen soll, dann gibts genug die man buchen kann.

Dieses abgeschotte gibts da einfach nicht, das ist irgendwie ein wesentlich
entspanteres entwickeln, da berechenbar (nur meine Meinung).

Aber zurück zu Foxpro.

Was würdest Du mir raten?
Ich finde das wir versierte Foxpro Spezialisten haben, mit denen die Anwender und der Rest von uns gut können ist ein dickes Plus. Mal eben eine neue Anwendung backen ist auf jeden Fall nicht drin und mit Foxpro machen wir nun mal seit jahren unsere Kohle

[robert.oh.]

Hallo,

Ich hab selber sechs Jahre lang VFP Applikationen (VFP 6 - 9) entwickelt und gewartet und in all den Jahren hab ich mich mit VFP wirklich 'angefreundet' - aber man entwickelt sich weiter und deshalb bin ich nun bei .NET (C# 2.0 / 3.0, LINQ, WPF, WCF, ASP.NET, VB.NET, usw) angelangt.

Der Umstieg auf VFP 9 ist meiner Meinung und Erfahrung nach nicht soooo schwierig, denn wenn man zwei SET Commands absetzt, reagiert der Compiler 'fast' wie unter VFP 6 und man braucht ansonsten nichts zu aendern.

SET ENGINEBEHAVIOR 70 && Group By Verhalten in Selects
SET REPORTBEHAVIOR 80 && regelt das Verhalten der Reports

Ich will eure VFP Experten damit in keinster Weise angreifen oder aehnliches.


Fuer die Zukunft ist sicher erst einmal abzuklaeren, wo man hin will (Plattform; .NET laeuft zwar mittels MONO Project auch unter *ix und Apple aber nur in der Basisfunktionalitaet) und als naechsten Schritt sollte man dann (meiner Meinung nach) die Programmierumgebung anhand der zur Verfuegung stehenden Resourcen (hat man .NET / Java / ... Entwickler im Team) waehlen.

Das Endergebnis unterscheidet sich - streng genommen - nur minimal im Layout und programmieren muss man da und dort.

[marc9022]

An der ASP.NET Applikation hängen ja schon ein paar Leute dran, aber ehrlich gesagt halte ich das für großen Murks, da Browsersachen schon mal kompliziert werden können, mangels Struktur.

HTML-War ja nicht dazu gemacht worden,also strickt man fleissig rund herum
und nutzt CGI artige Dinge die via HTML Formular, datenbankbasiert mehr oder minder sinnvolle Sachen ausgeben ;d

Nur, wenn der Popupblocker zuschlägt, der User die Session verliert oder
ein antiviren Jäger oder die Personalfirewall dazwischen funkt ist der Anruf
des Kunden sicher.

Darüber hinnaus erinnert mich der Codematsch den der Visual HTML-Designer
von ASP.NET 2008 erstellt übel an die ergüsse von Frontpage...

Bei einer alten Win32 MFC C++ Applikation habe ich da wesentlich mehr
Möglichkeiten, bestimmte Problemzonen zu umgehen. Ich muss nicht mal checken ob er das notwendige .NET Laufzeitzeugs installiert hat (da bekomm ich als nächstes nen Wutanfall!!).

Hab jetzt gerade herrausgefunden das aspnet_regiis.exe in 3.0 und 3.5
von .NET (Visual Studio 2008) nicht mehr dabei ist. Musste mir jetzt selber
in C++ ein Tool basteln das meine Web.Config verschlüsselt, weil kein Endanweder mit den Befehlszeilentools von .NET klar kommt und noch weniger mit der Doku von MS!

Eigentlich kann man von MS eigentlich nur die alten Sachen "sicher"
verwenden, weil sie so breitgetreten und nachgeflickt wurden das
sie "heute" zumindest laufen ;D (aber auf Vista und Servicepacks muss man
aufpassen und alles schön digital signieren!).

In 10 Jahren läuft bestimmt auch .NET hervorragend, aber heute muss ich
mich noch mit Sachen wie Frameworkchecks herrumschlagen, nachinstallieren
lassen, spätes linken bei DLL's funzt erst in .NET 3.5 (wichtig bei weitergabe
kompilierter DLL's als PlugIn) u.s.w

Das mit den DLL's ist der Hammer, vor allem weil Du es unter Win32 schon
ewig hast. Wenn Du was vergleichbares wie Loadlib haben willst, musst
Du auf so einen Dreck wie Reflections zurückgreifen. Entladen ist auch essig, da musst Du deine Hostanwqendung komplett terminieren oder
eine seperate AppDom erstellen... , nur um eine Funktion aus einer
.NET-DLL dynamisch laden zu können! Das wird als tolles Feature in
Visual Studio 2008 + .NET 3.5 verkauft! lol

Ich sagte ja, in 10 Jahren läufts bestimmt toll ;d

Meine empfehlung: Finger weg von Linq und vom Visual Designer!
Die Dinger generieren Dir einen teilweise unwartbaren Code aus dem Du nie
wieder schlau wirst, spätestens dann hat es sich mit den angeblichen Benefits, Produktivitätsvorteilen und der RAD-Applikationsentwicklung!

Als Programmierer musst Du deine Anwendung komtrollieren können
und nicht deine Entwicklungsumgebung Dich!

[Bernhard Geyer]

Bei ASP.NET lösungen wird "0815-" HTML-Code zum Client gesendet. Also nix mit .NET auf dem Client nötig. Das ist erst dann nötig wenn man Silverlight oder .NET Custom Controls verwenden will. Und bei "0815" HTML wird dir keine "normale" Firewall oder Virenscanner dazwischenfunken.

[marc9022]

Bei ASP.NET lösungen wird "0815-" HTML-Code zum Client gesendet. Also nix mit .NET auf dem Client nötig. Das ist erst dann nötig wenn man Silverlight oder .NET Custom Controls verwenden will. Und bei "0815" HTML wird dir keine "normale" Firewall oder Virenscanner dazwischenfunken.

In der Theorie ja und in der Praxis nein und das Ergebnis nennt sich Erfahrungswert!

Ausserdem ist es mitnichten nur HTML 4.01 <, sondern XHTML 1.0 / CSS1/CSS2
sammt JavaScript, AJAX und weiteren XML Elementen die automatisch generiert
und mit Viewstatecontroller Steuerung versehen ein undurchsichtiges wirrwarr erzeugt
wird, das für einen Programmierer nur schwer überschaubbar und wartbar bleibt
(muss er ja auch nicht, so lange Visual Studio selber noch damit klar kommt... aber
wehe dem wenn das mal nicht mehr klappt und MS mal wieder was geändert hat..
dann ist guter Rat Millionen wert - zu oft erlebt)

Dann kommt auch noch dazu, das die ASP-Taglib bestimmte Funktionen
unsichtbar im Hintergrund durchführen, die ebenfalls bzschwer nachzuvollziehen sind. Auch Datagrid Komponenten sind höchstproblematisch, weil wenn hier z.B ein Performanceproblem auftritt Du gar nicht die Möglichkeit hast etwas zu verändern, ausser durch überschreiben, was dann wieder zu einer derivaten Kapselung führt.

Auch Codebehind ist kritisch, da Du teilweise Kontrolle über die HTML-Tags verlierst b.z.w
nicht so frei wie bei PHP oder Servlets/JSP ASP 2.0 darauf zugreifen kannst. Wenn Du mal den
real existierenden Wahnsin einer komplett visuell erstellen ASP.NET Großanwendung sehen willst, geh mal auf partner.microsoft.com und bewundere die Performance und zig Fehlermeldungen ;D