Laden...

FoxPro als EmbeddedDB?

Letzter Beitrag vor 18 Jahren 48 Posts 11.624 Views
FoxPro als EmbeddedDB?

Ich würde gerne FoxPro statt Access als DB nutzen, welches ich mit meiner Anwendung gleich mitinstalliere...
Hat zur Nutzung von FoxPro mit C# evtl. jemand eine gute Seite die auf ein paar Sachen tiefer eingeht? Interessieren würde mich v.a. Multiuser-Zugriff, Triggers, Views, Stored Proecdures, etc...
Danke schonmal! 👍

Ach ja und was ich noch fragen wollte: Der Kern des Ganzen ist kostenlos und für Visual FoxPro muss ich pro Lizenz zahlen? Hab ich das richtig verstanden? Naja aber durchs MSDN-Abo hab ich schonmal eine Lizenz hier... 😁

Sicher, dass Du da wirklich VFP nehmen willst?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

ja bin ich, wieso? hängs jetzt nicht am multi-user zugriff oder den anderen sachen auf - die DB soll klein und schnell sein und mit einer anwendung installiert werden können...
der rest ist erstmal unwichtig, interessiert mich aber...

Dann würde ich eher SQLite oder FireBird-Embedded nehmen.

hi quest,

warum immer noch eine dateibasierte datenbank?

warum nicht msde oder gar sql server express 2005?

keine lizenzprobleme und gehen tut mehr als foxpro sich je träumen lassen wird 🙂

hth
ron

Vor allem würde ich nicht mehr auf eine Datenbank setzen, die nicht mehr weiterentwickelt wird ...

Ansonsten sehe ich das wie citizen.ron ... die Hochzeit von VFP ist vorbei (habe selbst beruflich VFP entwickelt, weiß also durchaus, wovon ich rede 😉) und der SQL Server kann definitiv deutlich mehr als VFP jemals kann.

Falls das Argument ist, dass Du keinen Dienst laufen haben willst, okay, das wäre für mich das einzige Argument, das für FoxPro spräche, allerdings gibt es dann auch modernere Lösungen ...

Allein, dass Du Dir in VFP eine Tabelle "zerschießen" kannst, finde ich heutzutage ein Unding ...

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

hmm, danke erstmal für eure antworten...

Falls das Argument ist, dass Du keinen Dienst laufen haben willst, okay, das wäre für mich das einzige Argument, das für FoxPro spräche, allerdings gibt es dann auch modernere Lösungen ...

genau das ist der punkt, deswegen bin ich ja überhaupt auf foxpro gekommen als alternative zu ms access weil zuverlässigkeit und speed höher sind...
die DB muss voll eingebettet sein und nix extra installieren oder einen dienst starten(!!), soll aber u.U. auch auf ein netzlaufwerk gelegt werden können, um von mehreren rechnern drauf zuzgreifen....

wie siehts bei foxpro eigentlich mit der lizenzierung aus? muss man, wenn man datenbanken mit seiner anwendung vertreibt, was berappen?

und wie ist die lizenzierung bei SQLite und firebird embedded?

und warum kann ich eine foxpro-DB "zerschiessen" aber eine firebird embedded-DB nicht? oder hab ich da was falsch verstanden?

VFP ist kostenlos, so lange Du nur die Runtime verwendest.

Wenn Du den Stecker ziehst, während VFP gerade am Machen ist, hast Du Dir vermutlich Deine Datenbankdatei zerschossen. ACID wird also nicht durchgängig unterstützt.

Wie das bei Firebird und Sqlite ausschaut, vermag ich nicht zu sagen, da ich weder das eine noch das andere System kenne.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

haben hier in der firma auch foxpro datenbanken auf die ich mit c# code zugreife
du brauchst dafür die foxprooledb-treiber, wirst also nicht drumherum kommen etwas installieren zu müßen
der zugriff erfolgt dann über die oledb-ado.net klassen

afaik ist es bei firebird nicht notwendig, da hast du deine datenbankdatei, deinen reinen managed provider und mußt nichts installieren

Müssen die VFP OLEDB-Treiber echt installiert werden? Kenne die nur vom Prinzip her, habe sie aber noch nie eingesetzt ... ich dachte, es reicht, die DLL in den korrekten Ordner zu kopieren?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

ok, das hab ich ehrlich gesagt nie probiert, da die treiber nur als installierbare setup-datei kommen

theoretisch müßte es reichen die in den ordner zu kopieren wo deine anwendung liegt... müßte man echt mal testen... würde ja einiges vereinfachen^^

ich kenn das von foxpro anwendungen her, das du dort nur die runtime files zu der exe kopieren brauchst...

Übrigens, so als Alternative .... was ist mit XML?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

ist zu langsam, n' paar tausend datensätze mal eben so zu durchsuchen dürfte sich damit nicht als allzu einfach rausstellen...
hmm als beste alternative sehe ich dann wohl firebird embedded? wobei ich noch nicht den wirklich vorteil sehe - zeitgemäßer soll es sein? aber warum denn jetzt eigentlich?

VFP ist IMHO unter anderem deshalb schon aus dem Rennen, weil es nicht mehr weiterentwickelt wird.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

Hmmm, aber wenn ich jetzt hier diese Roadmap lese dann klingt das doch eigentlich nicht sooo schlecht, jetzt Foxpro verwenden und dann '07 Sedna?

Wobei mich dann wieder solche Aussagen stutzig machen:

Visual FoxPro will remain stand-alone Win32 based, and will run on 64-bit Windows in 32-bit compatibility mode.

Daran siehts man wohl die stehengebliebene Entwicklung...

Nach Sedna wird es kein VFP 10 mehr geben .... und Sedna ist wohl auch eher für die letzten VFP-ler gedacht, um denen den Umstieg zu erleichtern.

Ansonsten sehe ich den Sinn nicht so ganz, aus VFP über Sedna über COM auf .NET zuzugreifen, wenn ich gleich .NET nehmen kann.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

ok, ich fange langsam an zu verstehen...

jedoch macht mich die folgende formulierung stutzig:

Ansonsten sehe ich den Sinn nicht so ganz, aus VFP über Sedna über COM auf .NET zuzugreifen, wenn ich gleich .NET nehmen kann.

ich dachte der zugriff über oledb einerseits auf foxpro oder andererseits z.B. auf firebird embedded ist genau dasselbe? warum ist das eine "mehr .NET" als das andere?

Auf VFP kannst Du aus .NET heraus zugreifen. Das ist die eine Sache. Daran ändert sich mit Sedna genau gar nichts.

Aus VFP kannst Du derzeit mehr schlecht als recht auf .NET zugreifen. Das ändert sich mit Sedna, da Sedna als Integrationsschicht zu verstehen ist.

In diesem Sinne sehe ich für VFP-Entwickler keinen Sinn, mit Sedna auf .NET zuzugreifen, da der Overhead massivst ist und man ja doch das .NET Framework benötigt.

Für .NET-Entwickler, die auf VFP zugreifen wollen, macht Sedna hingegen keinen Unterschied.

Klarer 😉?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

ja vielen dank,
jetzt verstehe ich auch endlich das interview, das in der roadmap referenziert wird...
ich muss also den oledb-treiber von foxpro mehr als möglichkeit sehen mein foxpro-zeugs mit .NET nutzen zu können...
wenn ich gleich aus .NET agiere dann doch bitte gleich eine embedded DB die extra dafür gemacht ist!
richtig so?

Joa, der OLEDB-Treiber stellt Dir einfach die Möglichkeit zur Verfügung, per OLEDB auf die FoxPro-Datenbanken zuzugreifen. Das war's. Er ist quasi die JetEngine für VFP-Dateien 😉.

Allerdings gibt es keine Embedded DB, die speziell für .NET gemacht wäre ... ich meine, Access zB wird ja auch nur per OLE DB angesprochen ...

Anders sieht es beim SQL Server aus, für den es zB einen nativen .NET-Provider gibt. Wie dies bei Firebird und Sqlite aussieht, weiß ich nicht.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

firebird embedded kommt mit einem eigenen ADO.NET provider...
was sind dadurch die vorteile?

ganz interessant dazu auch die folgende aussage:

Is the embedded Firebird a managed .NET assembly?
No. Fbembed.dll is a regular DLL library. Only the Firebird ADO.NET Provider (FirebirdSql.Data.Firebird.dll) is a fully managed code.

ole ist eine allgemeine schittstelle mit der du auf daten/datenbanken zugreifen kannst
odbc ist ja auch sowas
für die verschiedensten datenbanken giebt es treiber für odbc, oledb, etc.

wenn du oledb-ado.net benutzt, greifst du über diese schnittstellen auf die db zu
schreibst du einen eigenen, kannst du direkt drauf zu greifen
du kansnt sogar ado.net provider für tabsheet dateien schreiben, oder alles mögliche

die fbembeded.dll wird die runtime für die datenbank sein, quasi dein "server"
also diese dll greift dann auf die datenbankdatei zu und regelt die ganzen queries und so

der ado.net provider wird die aufrufe an diese dll kapseln... dadurch kann man eigene spezielle funktionen einbauen, optimierungen machen usw.

du kannst diesen eigenen ado.net provider mit den sql-ado.net provider von microsoft vergleichen, der wurde auch auf die datenbank direkt zugeschnitten und biete funktionen die nur sql server hat
theoretisch kannst du auch mit dem oledb provider auf sql server zugreifen, das ist dann aber sehr viel langsamer u.a.

Da ist man ein paar minuten draussen, da schafft ihr hier gleich 3 Seiten, tststs.

Zu SQLite und FireBird.
Beide haben volles Transactiongedöns, und volles ACID.

SQLite ist die std. DB bei PHP 5 und jetzt bei Sunbird.
Ist echt schnell, und besteht nur aus einer DLL ( oder 2 je nach Provider ).
( FW 1.1 und FW 2.0 beide auf sf.net ).

FireBird ist deshalb interessant, weil man mit dem ConnectionString
von einer Embedded-DB auf einen richtigen Server umstellen kann.

FireBird ist aus Interbase entstanden.

@fzelle: Entschuldige die 3 Seiten... 😁
das mit ACID ist schon interessant, den vorteil von firebird sehe ich auch ein, jedoch habe ich gelesen dass man die DB nicht auf ein netzlaufwerk legen kann (mehr dazu unten im link)

@sheitman: verstehe, das prinzip ist eigenlicht relativ einfach wenn man weiss was sich hinter welchem begriff versteckt...
der ganze embeddedDB-kram ist ja im prinzip die vereinfachung von servern auf datei-formate und der rest bleibt sich gleich..

ich habe folgenden blog entdeckt und ich mache teilweise den gleiche mist durch wie der kerl..
vistaDB hab ich auch schon getestet (sofort abgeschmiert, danach nicht mehr angerührt), mircosoft-lösung wegen der größe verworfen, etc etc...

lest euch mal den blog durch, sehr informativ 😁

hm, letzten endes hat er dann doch zu vistadb gegriffen... schade nur das dieses blogoffer nicht mehr aktuell ist X(

ich würd an deiner stelle nochmal die testen, die in deiner engeren wahl sind, bzw. mal schaun ob sich bei den bemängelnden db's was getan hat und ob du vistadb nicht doch zum laufen bekommst...

gibt es denn hier jemanden der schon erfahrung mit einigen embeded-dbs hat?

bin derzeit schwer am überlegen doch vista zu nehmen, denn fehler sind ja garantiert überall drin - hab auch schon nen workaround fürs abschmieren...
aber der erste eindruck hinterlässt doch immer spuren, denn ein schwerwiegender fehler der gleich dem starten des data builder auftritt hat schon was für sich - na ja des thema kann man anscheinend ja bis ins unendlich ausweiten wie der blog schön zeigt..

das einfachste wäre wenn microsoft endlich ihrem .NET eine embedded midsize DB spendieren würde, muss ja gar nicht soooo viel können, aber zumindest ein paar grundsätzliche funktionen beinhalten und sich mit ner kleinen dll zufrieden geben...
v.a. die verweise auf XML nerven mich, für config-files und minidatenbanken schön und gut.... 🤔
na ja und access als lösung zu nehmen widerstrebt mir ungemein (auch wenns wohl gerade so reichen würde von der performance her), aber wenn ich schon sehe dass sich die größe einer access-DB um mehr als die hälfte verringert nach einen "compact and repair"... 🙁

nachtrag: der support von vista ist auch nicht das gelbe vom ei, ein blick ins forum genügt - da kriegt man nur hilfe wenn man das teil schon gekauft hat...

was genau soll denn deine anwendung machen bzw. welche anforderung hast du an die datenbank?

Ich wüsste nicht, warum FireBird nicht auf einem Netz-LW laufen sollte.

Abgesehen von .NET Sicherheitssachen.

Und MS gibt Dir doch soetwas, in Form der Jet-Engine.

Die ist zwar nicht auf Multiuser ausgelegt, aber wer das braucht sollte eben
eine echte DB benutzen.

@sheitman:
es sollen zeitgebundene daten in der DB abgelegt werden, ich klicke also z.b. in der anwendung auf einen bestimmten button und möchte im kalender alle daten für den gewählten zeitraum anzeigen (es kann also passieren dass mal schnell viele daten "reingeholt" werden müssen) - theoretisch könnte ich das auch mit acces machen, aber aber aber....
die DB soll auch auf ein netzlaufwerk (ohne aufwand!) platziert werden können und für multiuser reicht mir das optimistic locking völlig...
da entstehen keine problem, aber ich halte von der access-lösung nunmal gar nix und deswegen gucke ich mich nach was anderem um - server ist zuviel denn die DB wird mit der application installiert und ein DB server ist einfach nicht nötig für den zweck...

lange rede kurzer sinn, firebird ist eigentlich genau richtig wenn ichs hinbringe den auf ein netzlaufwerk zu legen, ich werds heute mal testen...

@fzelle: s.o. g

Die Embedded-DB wird zukünftig SQL Server Express sein, der a) die Jet ablösen soll und b) statt ihrer in das OS integriert wird.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

Wozu DB-Files auf einem Netzlaufkwerk? Will man Mehrbenutzer-Zugriff braucht man in jedem Fall ein DBMS, sprich einen DB-Server. Für Einzel-Benutzer-DBs wäre das Netzlaufwerk sinnlos, weil das DB-File eh nur einmal geöffnet werden kann.

Zumal wenn ich es eh im Netzwerk ablege, kann ich auch gleich einen dedizierten DB-Server nehmen ...

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

mal angenommen ich hab 3-4 user die ab und an auf die daten zugreifen - passiert der seltene fall einer gleichzeitigen bearbeitung des gleichen datensatzes dann reicht das optimistic locking völlig...

es geht also darum die eigenen reingeschriebenen daten den anderen mit möglichst geringem aufwand lesend zur verfügung zu stellen - da ganze ist optional anzusehen!! sprich die meisten user werden ihre DB lokal auf ihrem PC haben und sich nie drum kümmern aber es wird auch einige user geben die gerne ihre DB sharen möchten, deswegen netzlaufwerk...
server mit DBMS braucht also ein großteil der user gar nicht und die fürs dies in frage kommen würde, kommen mit einem einfachen optimistic locking gut zurecht - jetzt brauch ich eine DB die das unterstützt und nicht so "anfällig" wie access ist - der ansatz von VistaDB ist genau das was ich brauche - der SQL Server Express ist noch nicht "klein" und "unaufwändig" genug...

Gerade hierfür ist doch FireBird der ideale einsatz.

Local mit der Embedded engine, im Netz den echten Server.

In deiner SW ist der unterschied nur der Connectionstring.

Natürlich gibt es DBs, die mit dem gleichen Provider in zwei Varianten (embedded und Server) angesprochen werden können, aber die embedded Variante ist immer Single-User, die andere Multi-User. Man kann das nicht switchen oder durch Kopieren eines Files eine Single-User-DB Multi-User-tauglich machen. Dieser Denkansatz ist falsch. Bestenfalls kann du wirklich eine Single-User-DB auf das Netz packen und hast so durch das File-Sharing eine "Zugriffskontrolle". Die betrifft aber die komplette DB, d.h. solange jemand auf der DB arbeitet kann niemand sonst dran arbeiten, wahrscheinlich auch nicht lesen. Da wird dann schon beim Aufbauen der Connection eine entsprechende AccessViolation kommen.

Hier hilft auch kein "selten" oder "manchmal", man muss sich entscheiden: Habe ich Multi-User-Zugriff oder nicht. Mit der Concurrency-Control hat das auch nix zu tun (gibts immer nur bei Multi-User).

wobei es bei meiner anwendung so ist dass eigentlich nie gleichzeitig in einen datensatz geschrieben bzw. die multi-user-umgebung, wie oben schon geschrieben, nicht wirklich eine multi-user umgebung in dem sinne ist - mehr oder weniger eher ein "lesendes sharen" der inhalte und ab und an mal was reinschreiben - ok ok ich bewege mich damit in einer grauzone und würde lieber gleich nen server benutzen, darf ich aber nicht...

wie dem auch sei, ich nehme mal den folgenden link als referenz - da wird auch so schön wischi-waschi formuliert und das eigentlich problem umgangen, aber für meine andwendung genügt das völlig und besser als das instabile access ist es allemal und(!) der user kann die datei auf ein netzlaufwerk legen ohne viel aufwand im gegensatz zu firebird...

hach ja, dieser thread wird immer krasser 8o

aber eins muss ich mittlerweile wirklich sagen: ich hasse es das file auf ein netzlaufwerk zu legen 🙁

Wie schon gesagt: "Eigentlich nie", "ab und an", usw. sind leider keine Grundlage für eine tragfähige Architektur. Was auftreten kann, _wird _auftreten.

Der Link ist spannend, weil es sich dabei in Wirklickkeit um ein verteiltes DBMS handelt, wobei der Datenzugriff über shared files erfolgt. Die einzelnen Clients sind zugleich auch Server und kommunizieren via P2P-Technlogie miteinander. Der Nachteil der Lösung ist klar: Langsam, weil die Sychronisation der Schreibzugriffe über das Netzwerk anstatt In-Memory erfolgt. In jedem Fall eine bessere Lösung als Access oder andere Single-User-DBs.

Ein weiterer Nachteil könnte die Konfiguration von Personal Firewalls sein. Anders als bei einem dezidierten Server muss hier mit Braodcasts (wer macht noch an meiner DB rum?) gearbeitet werden und auch das P2P erfordert die Freischaltung der Ports innerhalb des gesamten Netzwerkssegmentes. Innerhalb von Firmennetzen aber meist unkritisch.

An deiner Stelle würde ich den Firebird nehmen. Wie schon erwähnt wurde musst du nur den Connection-String anpassen, wenn du zw. Server und embeded wechseln willst. Das ist doch geil. Und der ADO.NET provider ist auch cool 8)

André

Original von Quest
der user kann die datei auf ein netzlaufwerk legen ohne viel aufwand im gegensatz zu firebird...

also geht das bei firebird nicht?
was genau ist den nda für aufwand zu treiben, wenn ich mal fragen darf?

Original von sheitman

Original von Quest
der user kann die datei auf ein netzlaufwerk legen ohne viel aufwand im gegensatz zu firebird...
also geht das bei firebird nicht?
was genau ist den nda für aufwand zu treiben, wenn ich mal fragen darf?

Das interessiert mich auch!
Bin nämlich gerade mit einer ähnlichen Problematik beschäftigt.

Grüße Christoph

Ich denke da gibt es ein Grundsätzliches Missverständnis einiger Entwickler,
die glauben, das wenn eine Anwendung eine Security Exception wirft,
das das ein Problem ist.

FireBird kann ganz locker auf DB-Dateien im Netzwerk zugreifen,
aber das macht dann meist nicht wirklich sinn.

Eine Multiuser-DB sollte immer auf einem Server laufen,
der die Koordination macht.

Aber gerade deshalb finde ich persönlich FireBird ja so genial.
Mit der Embedded Engine hast Du eine mächtige locale DB und wenn der
Multiuser-Betrieb gebraucht wird, wird der Server im Netz installiert und
nur der Connectionstring in der Anwendung geändert, Fertig.

Und der Server kan z.B. auch auf einem recht alten PC laufen, z.B. unter
einem kleinen Linux.

ok, hät mich nämlich auch gewundert.

überlicher weise kann man .net assemblies nicht vom netz ausführen, da wird eine security exception geworfen.
man kann das aber über policies anpassen, setzen wir hier auch (bald) so ein...

wenn du dein programm lokal ablegst und nur die datenbankdatei auf das netz legst müßte das schon funktionieren...

ich fände es auch ganz gut mit firebird zu arbeiten, denn falsl ihr doch mal umsteigen solltet hast du dann keine anpassung vorzunehmen 🙂

hmm, ich habe mich dabei auf diese aussage verlassen - so wie ers schreibt macht das gewissermaßen sinn...

firebird embedded ist nunmal drauf ausgelegt ein "lokaler server" zu sein, um das switchen auf einen echten DB-server so leicht wie möglich zu gestalten - bei der vista DB sind server und embedded engine wohl nicht in so hohem maße verknüpft...

aber mittlerweile bin ich echt soweit in den nächsten wochen alles mal zu testen (sowohl firebird als auch vista, sowohl auf netzlaufwerk legen und auch einen zugriff von zwei nutzern gleichtzeitig) - allein schon um zu sehen was dann passiert 😉

und bevor jetzt wieder alle schreien dass es nicht für multi-user betrieb gedacht ist: ja ich weiss, allerdings wäre es doch mal nett zu sehen was dann passiert (falls es überhaupt möglich ist) 😭

Hallo,

ein wenig spät, aber ich würde hier gerne ein paar Ungenauigkeiten klarstellen wollen.

Original von Quest
Ich würde gerne FoxPro statt Access als DB nutzen, welches ich mit meiner Anwendung gleich mitinstalliere...
Hat zur Nutzung von FoxPro mit C# evtl. jemand eine gute Seite die auf ein paar Sachen tiefer eingeht? Interessieren würde mich v.a. Multiuser-Zugriff, Triggers, Views, Stored Proecdures, etc...

VFP anstelle von Access zu verwenden, ist auf alle Fälle schon eine interessante Variante. Entsprechendes lässt sich auch der FAQ zu VFP bei Microsoft nachlesen: http://msdn.com/vfoxpro/

Ach ja und was ich noch fragen wollte: Der Kern des Ganzen ist kostenlos und für Visual FoxPro muss ich pro Lizenz zahlen? Hab ich das richtig verstanden? Naja aber durchs MSDN-Abo hab ich schonmal eine Lizenz hier... 😄

Du musst lediglich für eine Entwicklungsumgebung bezahlen. Der weitere Vertrieb deiner Anwendung ist dir überlassen. Weiterhin möchte ich hierzu sagen, dass der Ole DB Provider für VFP ebenfalls online frei verfügbar ist und du damit eigentlich alles hast, um VFP als Datenbank zu verwenden.

In meinem Blog findest du übrigens ein fertiges Beispiel mit allem Drum und Dran. Sogar die Erstellung der Datenbank mit den Tabellen kannst über ADOX und ADO.NET erledigen.

So, damit wäre deine initiale Frage beantwortet, schauen wir uns die weiteren Statements an und kommentieren das ein wenig...

Original von citizen.ron
keine lizenzprobleme und gehen tut mehr als foxpro sich je träumen lassen wird

Welche Lizenzprobleme hat man denn mit VFP? Genau das ist doch der Haken, dass Microsoft das Produkt in den letzten Jahren sehr stiefmütterlich betrachtet hat. Und gerade in Bezug auf Verwendung mit ADO.NET ist es erst recht kostenfrei: http://msdn.com/vfoxpro/ dort gibt's den Ole DB Provider und das war's dann auch schon. Mehr ist nicht notwendig.

Original von Der Eisbär
Vor allem würde ich nicht mehr auf eine Datenbank setzen, die nicht mehr weiterentwickelt wird ...

Ansonsten sehe ich das wie citizen.ron ... die Hochzeit von VFP ist vorbei (habe selbst beruflich VFP entwickelt, weiß also durchaus, wovon ich rede 😉) und der SQL Server kann definitiv deutlich mehr als VFP jemals kann.

Zunächst einmal ist VFP ein Produkt, welches seit annähernd 20 Jahren besteht und damit die entsprechende Reife aufzuweisen vermag. Der Produktsupport seitens Microsoft läuft irgendwann 2014 aus. Bis dahin läuft sehr viel Wasser den Rhein hinunter. Weiterhin finde ich es übrigens sehr spannend, dass gerade die Entwicklung von LINQ speziell auf die Features von VFP eingeht und sich daran orientieren wird. Oder wie erklärst du die Integration von Rushmore in .NET 3.0?

Über deine Kenntnisse in Bezug auf VFP möchte hier nicht weiteres zum Besten geben, außer dass du kaum mit der eigentlichen Datenbank in Kontakt gekommen bist, da wir im Projekt primär mit dem MS SQL Server (bedingt durch Anforderung des Kunden) arbeiten. Ergo, bezieht sich dein "Wissen" primär auf die Programmiersprache denn auf die Datenbank.

Original von Der Eisbär
VFP ist IMHO unter anderem deshalb schon aus dem Rennen, weil es nicht mehr weiterentwickelt wird.

Wo bitte steht dieses Statement? Microsoft hat keine Aussage dazu getroffen. Es wird derzeit an Sedna programmiert, welches als Addon zu VFP 9.0 derzeit angesehen wird. Ob daraus VFP 10 wird oder nicht, entscheidet sich frühestens Mitte/Ende 2007.

Original von Der Eisbär
Aus VFP kannst Du derzeit mehr schlecht als recht auf .NET zugreifen. Das ändert sich mit Sedna, da Sedna als Integrationsschicht zu verstehen ist.

In diesem Sinne sehe ich für VFP-Entwickler keinen Sinn, mit Sedna auf .NET zuzugreifen, da der Overhead massivst ist und man ja doch das .NET Framework benötigt.

Und was hat das mit der Frage in Bezug auf die reine VFP-Datenbank zu tun? Ehrlich gesagt, sehe ich hier das Dilemma, dass du VFP immer als Ganzes betrachtest und entsprechend bewertest. Aber eigentlich entspricht VFP 3 Produkten: Programmiersprache, Datenbank und Reportsystem. Was meinst du wie glücklich irgendwelche Office-Anwender sind, wenn man denen einen VFP-COM-Server zur Verfügung stellt, so dass sie stressfrei im Vergleich zu ADO auf ihre Datenquellen kommen...

Achja, der Zugriff auf .NET funktioniert genauso wie bei anderen Nicht-.NET-Sprachen: per COM und das klappt gut. Selbst WinForms lassen sich per COM starten und nutzen.

So, Schnitt. Der Beitrag kommt wahrscheinlich ziemlich spät, aber ändert nichts an den Kommentaren. Ich möchte hier keine Lanze für VFP als lokale DB-Engine für .NET brechen, sondern es kommt auf die jeweiligen Anforderungen an das System an. Sicherlich lässt sich das gleiche Problem auch mit SQLite, Firebird und anderen RDBMS lösen.

Als VFP-Coder tendiere ich selbstredend für VFP als Datenbank, schliesslich sind wir alle subjektiv in unseren Aussagen.

Bis denne, JoKi

Bis denne, JoKi

Enjoy AFP FAQ - Participate AfpWiki - Get Blogged by JoKi - Talk to me at VFP User Group Meeting

Hi

ich halte auch VFP als Backend für kleinere Anwendungen, vorallem bei ungeschulten Anwendern, für sehr sinnvoll.

Access ist ja praktisch garkeine Datenbank 😉 Insofern wenn die Wahl zwischen vFP und Access steht auf jedenfall VFP.

Etwas bei dem der Eisbaer recht hat ist, dass die ganze Comunity hinter VFP klein ist (in .NET Maßstäben mal gesehen) und dementsprechend gibt es für die Anwendungsentwicklung auch nicht so viele Möglichkeiten.

Aber einfach die DBist einfahc zu handhaben, liegt im Fileformat vor (Kann der User selbst einfach mal umkopieren) und ist einfach praktisch.

Gerade bei Produkten für Private Endkunden finde ich es nicht gerade vorteil hast einen SQL Express ( oder MSDE etc) zu installieren.
Denn erstens verwirrt es den Kunden, Zweitens kann ers nicht programmieren, drittens sind Fehler durch falsches handling (anhalten von diensten , deinstallieren von SQL Server komponenten) vorprogrammiert.

Mein Stackoverflow Profil
Skype Name : Boas.Enkler (bitte einen hinweis in der Kontaktanfrage damit ich euch vom Spam unterscheiden kann)

Hi,

im großen und ganzen kann ich Dir folgen, auch wenn ich es ein wenig anders sehe, aber nun gut ...

Wo ich aber nicht mitkomme, ist hier:

Original von Haggy
Denn erstens verwirrt es den Kunden, Zweitens kann ers nicht programmieren, drittens sind Fehler durch falsches handling (anhalten von diensten , deinstallieren von SQL Server komponenten) vorprogrammiert.

Ad 1 - Wieso "verwirrt" ein SQL Server Express den Kunden? Der sieht davon doch genauso wenig wie von der Jet Engine?

Ad 2 - Inwiefern kann ein SQL Server Express nicht programmiert werden im Vergleich zu VFP?

Ad 3 - Du beziehst Dich speziell auf "private Kunden", was haben die bitte schön in der Diensteverwaltung zu suchen? Und wenn ich was deinstalliere, sollte ich wissen, was ich mache ...

Als Argument für den SQL Express sehe ich eher, dass der SQL Server zukünftig eh mehr in Windows integriert werden wird (Stichwort WinFS), so dass über kurz oder lang eh diese DB vorhanden ist.

Viele Grüße,

Golo

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

Ja ich glaube auch unsere Meinungen liegen gar nicht soweit von einander entfernt 😉

>>Ad 1 - Wieso "verwirrt" ein SQL Server Express den Kunden? Der sieht davon doch genauso wenig wie von der Jet Engine?<<
War nicht gut von mir formuliert, ich meinte mehr die MSDE , bei der unten ein TrayIcon da war.

>>Ad 3 - Du beziehst Dich speziell auf "private Kunden", was haben die bitte schön in der Diensteverwaltung zu suchen? Und wenn ich was deinstalliere, sollte ich wissen, was ich mache ...<<
Du glaubst gar nicht was ich schon alles bei endkunden erlebt hatte...
Das fängt damit an dass Sie diense anhalten, weil sie "mal gehört hatten dass es Speicher spart", Geht über das Löschen von Datenbankdateien ausserhlab des Programmverzeichnisses ("Es ist ja nicht in der Anwendung").

Diese Fälle beziehen sich eben auf den typischen DAU Anweder, der eben auch nicht auf seine Software (Fahrschülerverwaltung,Terminverwaltung,Rechnugnssoftware....) verzichten möchte.
Das schlimme daran ist, dass es eben oft nur halbwissen gibt und da oft und viel rumgeclickt wird.

>>Als Argument für den SQL Express sehe ich eher, dass der SQL Server zukünftig eh mehr in Windows integriert werden wird (Stichwort WinFS), so dass über kurz oder lang eh diese DB vorhanden ist.<<
Das Argument finde ich entscheidet. Wenns praktisch als Teil des BEtriebssystems ein e Datenbank gibt (Ähnlcih wie der Object Store auf dem PPC) dann und die auch performant läuft würde ich wohl auch eher dazu tendieren.

Aber WinFS braucht wohl noch eine Weile und soll nicht mal mehr in dem ersten Vista Release enthalten sein (oder gibt aktuellere infos?) und insofern wirds noch eine Weile dauern bis Vista inkl. WinFS zum Standard wird.

Mein Stackoverflow Profil
Skype Name : Boas.Enkler (bitte einen hinweis in der Kontaktanfrage damit ich euch vom Spam unterscheiden kann)

Original von Haggy
>>Ad 1 - Wieso "verwirrt" ein SQL Server Express den Kunden? Der sieht davon doch genauso wenig wie von der Jet Engine?<<
War nicht gut von mir formuliert, ich meinte mehr die MSDE , bei der unten ein TrayIcon da war.

Okay. Du meinst den SQL Server Manager (hieß das Ding so?), mit dem man die einzelnen SQL-Dienste starten und anhalten usw. konnte?

Original von Haggy
Du glaubst gar nicht was ich schon alles bei endkunden erlebt hatte...
Das fängt damit an dass Sie diense anhalten, weil sie "mal gehört hatten dass es Speicher spart", Geht über das Löschen von Datenbankdateien ausserhlab des Programmverzeichnisses ("Es ist ja nicht in der Anwendung").

Diese Fälle beziehen sich eben auf den typischen DAU Anweder, der eben auch nicht auf seine Software (Fahrschülerverwaltung,Terminverwaltung,Rechnugnssoftware....) verzichten möchte.
Das schlimme daran ist, dass es eben oft nur halbwissen gibt und da oft und viel rumgeclickt wird.

Fullack. ABER - wenn jemand C:\Windows\Assembly löscht, fliegt er auch auf die Schnauze mit .NET-Anwendungen. So was finde ich ist keine Aufgabe der Anwendung, Halbwissen und Verantwortungslosigkeit der Anwender abzufangen. Wird ja zum Glück in Vista schwieriger ...

Original von Haggy
Aber WinFS braucht wohl noch eine Weile und soll nicht mal mehr in dem ersten Vista Release enthalten sein (oder gibt aktuellere infos?) und insofern wirds noch eine Weile dauern bis Vista inkl. WinFS zum Standard wird.

Es wird im ersten Release vom Longhorn Server enthalten sein, in Vista wohl leider wirklich nicht. Trotzdem frage ich mich, was nachher leichter umzustellen ist, eine bestehende SQL Express-DB oder halt ein anderes Format.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de