Laden...

mehrere datenbanken verknüpfen ?

Erstellt von romu2000 vor 18 Jahren Letzter Beitrag vor 18 Jahren 8.587 Views
R
romu2000 Themenstarter:in
291 Beiträge seit 2006
vor 18 Jahren
mehrere datenbanken verknüpfen ?

Hallo zusammen,

nachdem ich nun mehrere tutorials durchgearbeitet habe, bin ich an meine grenzen gestossen.

uich arbeite mit dem visual studio c# express edition.

was ich bereits geschafft habe:

ein winform zu füllen aus einer visual fox pro datenbank.

mein problem:

zu den kundensätzen aus visual foxpro gibt es noch eine access datenbank die anhand der kundennummer mit visual foxpro verbunden war.

hat in access alles wunderbar funktioniert.

nur wie funktioniert das ganze mit c# ??

ich habe versucht ein neues dataset anzulegen, was auch funktioniert. nur wie bekomme ich die verknüpfungen beider datasets zustande???

viele grüße

ronny

3.728 Beiträge seit 2005
vor 18 Jahren
Verknüpfungen

In Access gibt es die Möglichkeit Tabellen zu verknüpfen. Das bedeutet, dass Access im Hintergrund eine ODBC-Verbindung zu einer anderen Datenbank hält und über diese Verbindung dort auf die Daten zugreift. Die Tabellen werden dann in Access wie normale Access-Tabellen angezeigt (Nur dass sie ein anderes Symbol haben) und können auch so verwendet werden. Du kannst ja z.B. einen SQL-JOIN über eine Access-Tabelle und eine verknüpfte Tabelle aus der FoxPro Datenbank machen.

Diese Dinge musst Du in C# "von Hand" erledigen.

Da Du zwei Datenbanken hast, brauchst Du auch zwei Verbindungen (also zwei OleDbConnections). Wenn Du Daten aus beiden Datenbank innerhalb einer Funktion brauchst, musst Du die Daten eben nacheinander abrufen.

Angenommen Du hättest die Kunden in FoxPro und die Angebote dieser Kunden in Access. Dann könntest Du so vorgehen, um z.B. alle Angebote von Kunden im Verkaufsgebiet Nord zu bekommen:
*Verbindung zu FoxPro öffnen *Kunden im Verkaufsgebiet Nord abrufen (SELECT KundenNr FROM Kunden WHERE Verkaufsgebiet='Nord') *Verbindung zu FoxPro schließen *Verbindung zu Access öffnen *Passende Angebote abrufen: SELECT * FROM Angebote WHERE KundenNr IN (231,761,412,8756,431, ...) *Verbindung zu Access schließen

Du solltest allerdings überlegen, ob es nicht sinnvoller ist, für jede Datenbank eigene Datenzugriffsfunktionen zu schreiben und diese in der Geschäftslogik zu verwenden. Ich kann das nur dringend empfehlen. In spätestens 2 Jahren wird Dein Code sonst so vertrakt und undruchsichtig sein, dass sich niemand mehr traut ihn anzufassen.

Noch eine Alternative wäre, alles auf den den SQL Server zu migrieren (Access 2000 oder höher hat dafür extra einen sogenannten Upsizing-Wizard) und das hässliche Access und FoxPro Gerümpel zu entsorgen. Das hängt allerdings sehr davon ab, wie groß die bestehende Lösung ist. Bei SQL Server ist es ohne weiters möglich auf andere Datenbanken zuzugreifen.

R
romu2000 Themenstarter:in
291 Beiträge seit 2006
vor 18 Jahren
Sql Server

HEY RAINBIRD,
danke für deine ausführliche antwort.

ich habe 2 möglichkeiten...

entweder ich portiere alle access daten zu foxpro, da das wawi programm auf foxpro basiert, oder ich portiere alles auf mssql und muss trotzdem 2 datenanbindungen über oledb zu realisieren?

wie siehts aus wenn ich 2 db´s verwende, zwecks performance...

ist es nicht ratsam alles auf einer db zu machen?

welche lösung würdest du befürworten?

viele grüße

ronny

432 Beiträge seit 2005
vor 18 Jahren

hey ronny

es ist definitiv immer am sinnvollsten, sowenig datenbanken wie möglich zu haben.

der theorie nach ist es ja so: EIN unternehmen hat meist EIN geschäftsgebiet und alle daten, die dieses unternehmen sammelt, sollten auch mit DIESEM geschäftsgebiet zusammenhängen. damit hängen sie natürlich auch MITEINANDER zusammen und deshalb sollte ein unternehmen auch nur EINE datenbank haben.

dabei vergessen wir für einen kleinen augenblick natürlich einfach mal, was im laufe der jahre so "historisch gewachsen" ist 😉

ausserdem hättest du ja dein verknüpfungsthema auch damit erschlagen, nur EINE datenbank zu haben und deren modell bei der migration gleich mit zu bereinigen...

frohe ostern

ron

3.728 Beiträge seit 2005
vor 18 Jahren
Datenbanken

Wenn möglich alles in eine Datenbank. Geschwindigkeitsmäßig bringt die Aufteilung in verschiedene Datenbanken nichts. Dazu gibt es die Möglichkeit in SQL Server Datenbanken auf verschiedene physikalische Dateien aufzuteilen.

Wenn es allerdings zwei getrennte Projekte sind, die getrennt weiterentwickelt werden sollen, kann es auch sinnvoll sein, zwei getrennte Datenbanken aufzubauen. Beide Systeme sollten dann aber nur über definierte Schnittstellen miteinander kommunizieren (Also keine direkten DB-Zugriffe, sonst kann alles gleich in eine DB).

FoxPro ist tot! In der Microsoft Welt ist SQL Server die Datenbank der Wahl.

R
romu2000 Themenstarter:in
291 Beiträge seit 2006
vor 18 Jahren
Mssql

hallo nochmal,

Stand der Dinge ist folgender:

wir haben ein WAWI - Programm welches aufgrund der großen Datenmengen auf FOXPRO basiert ( wird wahrscheinlich in naher zukunft vom Hersteller auf MSSQL - umgerüstet.)

Desweiteren haben wir auf die Kundenstammdaten per ODBC mit ACCESS zugegriffen und dort eine Art Telefoniesoftware laufen, die zu jedem Kundendatensatz diverse Kontakte, Briefe, Telefongesprächsdauer in eine ACCESS datenbank geschrieben hatte.

Mein Wunsch wäre es jetzt natürlich, alle ACCESS Daten in MSSQL zu konvertieren und dann mit C# auf FOXPRO (solange noch nicht auf MSSQL umgeschrieben) und MSSQL (ehemalige ACCESSdaten ) zuzugreifen.

Doch hier stellt sich schon das erste Problem:

Wie kann ich C# dazu bringen auf einem FORM (Dialog) 2 verschieden Connectionstrings zu verwenden , die dann auch noch anhand der "Kdnr" mit einander verbunden sind?

Habe ich einen Connectionstring, ist das ja mit dem DataDesigner kein Problem (Fill,GetData)...und dann die tabellen verknüpfen.

Hat irgendjemand eine leicht verständliche Lösung parat ???

Viele Grüße

Ronny

128 Beiträge seit 2004
vor 18 Jahren

Mahlzeit,

Original von Rainbird
Wenn möglich alles in eine Datenbank. Geschwindigkeitsmäßig bringt die Aufteilung in verschiedene Datenbanken nichts. Dazu gibt es die Möglichkeit in SQL Server Datenbanken auf verschiedene physikalische Dateien aufzuteilen.

Wenn es allerdings zwei getrennte Projekte sind, die getrennt weiterentwickelt werden sollen, kann es auch sinnvoll sein, zwei getrennte Datenbanken aufzubauen. Beide Systeme sollten dann aber nur über definierte Schnittstellen miteinander kommunizieren (Also keine direkten DB-Zugriffe, sonst kann alles gleich in eine DB).

Auf alle Fälle. Und so wie es sich anhört scheinen es auch zwei unterschiedliche Produkte, bzw. eine Access-Erweiterung zu einem VFP-Warenwirtschaftssystem zu sein.

FoxPro ist tot!

*gäääähn* - Sorry, aber der Spruch hält sich nun seit 10+ Jahren und das Produkt ist immer noch auf dem Markt und es sicherlich auch noch bis mindestens 2014 bleiben.

Und umgekehrt mal die Frage: Wenn VFP so schlecht ist, wieso werden dann gerade bei Microsoft dessen Features bzw. DataBinding und so in .NET 3.0 eingebaut? Was meinst du auf welchem Ansatz eigentlich LINQ basiert?

In der Microsoft Welt ist SQL Server die Datenbank der Wahl.

Prinzipiell korrekt aber sicherlich nicht für alle Anforderungen.

Bis denne, JoKi

Bis denne, JoKi

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

4.207 Beiträge seit 2003
vor 18 Jahren

Original von JoKi

FoxPro ist tot!
*gäääähn* - Sorry, aber der Spruch hält sich nun seit 10+ Jahren und das Produkt ist immer noch auf dem Markt und es sicherlich auch noch bis mindestens 2014 bleiben.

Und umgekehrt mal die Frage: Wenn VFP so schlecht ist, wieso werden dann gerade bei Microsoft dessen Features bzw. DataBinding und so in .NET 3.0 eingebaut? Was meinst du auf welchem Ansatz eigentlich LINQ basiert?

Ich sehe das wie Rainbird - FoxPro ist tot. FoxPro wird es nicht für 64 Bit geben. FoxPro wird nicht in Visual Studio integriert (wie sonst aber wirklich alles, was auch nur ansatzweise mit Development zu tun hat). Es wird keine FoxPro-Sprache für .NET geben. Und und und ...

Dass einige Ideen, die in FoxPro stecken, gut sind, streitet ja niemand ab. Dass man aber auch eine gute Idee schlecht umsetzen kann - oder, um das subjektive "schlecht" durch einen etwas weniger subjektiven Ausdruck zu ersetzen, dass eine Umsetzung einer guten Idee irgendwann auch einmal einfach nicht mehr zeitgemäß sein kann, ändert nichts an einem überholten Produkt oder einer guten Idee.

Klar kann man FoxPro für Linq ausschlachten, aber FoxPro an sich hat seinen Zenit überschritten.

Und ja, ich sehe FoxPro hier als Ganzes, das heißt, inklusive IDE und inklusive der Programmiersprache. Die gehören nun mal auch dazu. Und als Datenbank kann FoxPro sonst wie toll sein, als Gesamtprodukt (und als das wird es verkauft) hat es meiner Meinung nach wie gesagt seinen Höhepunkt weit hinter sich gelassen.

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

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

128 Beiträge seit 2004
vor 18 Jahren

Hallo,

hierfür hast du mehrere Lösungsmöglichkeiten.

Original von romu2000
Mein Wunsch wäre es jetzt natürlich, alle ACCESS Daten in MSSQL zu konvertieren und dann mit C# auf FOXPRO (solange noch nicht auf MSSQL umgeschrieben) und MSSQL (ehemalige ACCESSdaten ) zuzugreifen.

Wie kann ich C# dazu bringen auf einem FORM (Dialog) 2 verschieden Connectionstrings zu verwenden , die dann auch noch anhand der "Kdnr" mit einander verbunden sind?

Zunächst einmal kannst du beliebig viele Connections in deiner Form verwenden. Es spricht überhaupt nichts dagegen, dass du beispielsweise zwei und mehr Connections gleichzeitig offen hast und darüber multiple DataSets produzierst. In ADO.NET hast du sämtliche Freiheiten, um die beiden Backends auf dem Client zusammenzuführen und wieder zu splitten. Auch Relationen zwischen den unterschiedlichen DataSets der beiden Backends kannst du in ADO.NET volatil auf dem Client erzeugen und nutzen. Meine Empfehlung wäre hier, dass du dir mal ein, zwei Bücher zu den Fähigkeiten von ADO.NET durchliest.

Zweite Variante: Wenn ihr eh auf MS SQL Server migrieren wollt, dann würde es sich anbieten, dass die C# Anwendung gleich ausschliesslich auf den MS SQL Server zugreift und somit nur eine Connection benötigt.
Damit das schön funktioniert, musst du dir mal das Feature "Linked Server" vom SQL Server ansehen. Dort hast du die Möglichkeit per ODBC und OLE DB wiederum weitere Datenbanken in den SQL Server zu verlinken und über eine Schnittstelle anzusteuern. Das Konzept ähnelt den Linked Tables in ACC. Somit kann deine C#-Anwendung immer auf den SQL Server zugreifen und über die Links ebenfalls Daten aus den ACC-Tabellen wie auch aus den VFP-Tabellen ziehen.

Visual FoxPro als Linked Server einzusetzen, funktioniert ziemlich gut. Du solltest jedoch beachten, dass der DBC und die DBFs für den SQL Server lokal (also gleiche Maschine) zur Verfügung stehen. Anderfalls könntest du leichten Trouble mit Benutzer und Zugriffsrechten im Netzwerk bekommen.

Bis denne, JoKi

Bis denne, JoKi

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

128 Beiträge seit 2004
vor 18 Jahren

Hallo Golo,

Original von Golo Haas

Original von JoKi

FoxPro ist tot!
*gäääähn* - Sorry, aber der Spruch hält sich nun seit 10+ Jahren und das Produkt ist immer noch auf dem Markt und es sicherlich auch noch bis mindestens 2014 bleiben.

Und umgekehrt mal die Frage: Wenn VFP so schlecht ist, wieso werden dann gerade bei Microsoft dessen Features bzw. DataBinding und so in .NET 3.0 eingebaut? Was meinst du auf welchem Ansatz eigentlich LINQ basiert?

Ich sehe das wie Rainbird - FoxPro ist tot. FoxPro wird es nicht für 64 Bit geben. FoxPro wird nicht in Visual Studio integriert (wie sonst aber wirklich alles, was auch nur ansatzweise mit Development zu tun hat). Es wird keine FoxPro-Sprache für .NET geben. Und und und ...

Und? Wenn interessiert das? Dem Kunden ist es ehrlich gesagt piepegal, mit was das System entwickelt ist und auf welcher Datenbank es basiert. Hauptsache, er hat die wenigstens Kosten damit, das System läuft stabil und performant. Jedes andere DBMS außer dem SQL Server integriert sich ebenfalls nicht in VS - und? 8)

Und ja, ich sehe FoxPro hier als Ganzes, das heißt, inklusive IDE und inklusive der Programmiersprache. Die gehören nun mal auch dazu. Und als Datenbank kann FoxPro sonst wie toll sein, als Gesamtprodukt (und als das wird es verkauft) hat es meiner Meinung nach wie gesagt seinen Höhepunkt weit hinter sich gelassen.

Es freut mich, dass du diese Meinung hast. Die Realität sieht dennoch ein wenig anders aus. Und mal nebenbei bemerkt. Ich behaupte ja nicht, dass VFP ewig aktiv sein wird. Wer weiß, was Microsoft in den nächsten Monaten vor hat und gedenkt umzusetzen. I don't know. In Bezug auf deine Aussage bzgl. Zenit überschritten... Komisch, dass die letzten Monate des Tiobe Index für VFP starke Tendenzen nach oben aufweisen. Naja, aber weißte, du hast sicherlich recht mit deiner Meinung und letztendlich kommt es allein auf den Kunden an, was die Anforderungen sind. Wie diese zu erfüllen sind, obliegt dann dem Entwicklerteam. Und man dazu dann VFP, C#, VB, SQL Server, MySQL oder sonst was nutzt, ist doch abhängig von den Anforderungen.

Deine persönliche Aversion gegen VFP in Ehren, aber selbst SQL Server ist nicht immer die beste Lösung - nur scheint mir hier der Eindruck zu sein, dass du dir dessen in keinster Weise bewusst ist.

Mal was anderes: Was hat deine platte Aussage zu VFP eigentlich mit der Problemstellung hier in diesem Thread zu tun? Es wäre sicherlich wesentlich hilfreicher, wenn du Lösungen statt Meinugen posten würdest. Aber hey, ich möchte dir nichts vorschreiben - in deiner Community.

Bis denne, JoKi

Bis denne, JoKi

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

R
romu2000 Themenstarter:in
291 Beiträge seit 2006
vor 18 Jahren
Mysql ?

Hallo zusammen,

danke für die Meinungen und Lösungsvorschläge 🙂

Habe das jetzt soweit schon mal hinbekommen, ACCESS und FOXPRO auf einem FORM anzuzeigen ....

Nachdem ich jetzt mal gegooglet hatte und gesehen habe, dass ein SQL SERVER ja für lockere 10000+€ zu bekommen ist, wollte ich mal fragen was Ihr denn als alternative zu der Kostspieligen SQL SERVER Geschichte haltet, MYSQL einzusetzen.

Viele Grüße

Ronny

128 Beiträge seit 2004
vor 18 Jahren

Hallo,

Original von romu2000
Habe das jetzt soweit schon mal hinbekommen, ACCESS und FOXPRO auf einem FORM anzuzeigen ....

Na also... Und, schwierig?

Nachdem ich jetzt mal gegooglet hatte und gesehen habe, dass ein SQL SERVER ja für lockere 10000+€ zu bekommen ist, wollte ich mal fragen was Ihr denn als alternative zu der Kostspieligen SQL SERVER Geschichte haltet, MYSQL einzusetzen.

Ehrlich gesagt, kommt es ganz auf deine Anforderungen an. Die Variante, dass man MySQL in er aktuellen 5er Version einsetzt, ist zwar ganz nett, aber lassen sich damit deine Probleme lösen - das ist doch die wichtige Frage.

Wenn es um einen vergleichbaren SQL Server statt dem Produkt von Microsoft geht, dann tendiere ich sehr gerne zu PostgreSQL. Das läuft seit der Version 8.0 nativ auf der Windows Plattform und bietet etliches an Möglichkeiten. Aber auch hier gilt wiederum, dass du es mit deinen Anforderungen vergleichen musst. Es ist sicherlich nicht verkehrt, wenn du dir evtl. ein paar Tage Zeit nimmst und die einzelnen Produkte antestet bzw. dich im Handbuch umsiehst. IMHO sollte soviel Zeit bleiben.

Die sicherlich interessanteste Lösung dürfte es aber letztendlich sein, wenn du deinen Datenbankzugriff vollständig kapselst. Dann ist es nämlich schlichtweg egal, welches DBMS unter der Haube steckt... SQL Server, MySQL, VFP, etc...

Und für die Erstellung dieser DataAccessProvider empfehle ich dir, dass du dir mal die Artikel und Whitepapers auf http://www.vfpconversion.de durchliest. Das ist unter anderem auch speziell für Füchse mit Tendenzen zum .NET Framework gedacht. Im übrigen findet im Juni noch ein Workshop im deutschsprachigen Raum statt - vielleicht wäre das ja ebenfalls etwas für dich / euch.

Bis denne, JoKi

Bis denne, JoKi

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

R
romu2000 Themenstarter:in
291 Beiträge seit 2006
vor 18 Jahren
hmmmm

hallo mal wieder,

ich denke das es wohl das beste sein wird, die 2te datenbank auf mysql aufzusetzen....(@yoki --> wir selber arbeiten ja nicht mit VFP - so wurde nur das WAWI programm erstellt auf dessen kundenstammdaten ich lediglich zugreifen möchte.)

Ich habe nochmal eine grundlegende Frage:

das mit den beiden datasets funktioniert doch nicht so wie es mir vorstelle.

Wie sollte ich denn am besten vorgehen um die beiden datenbanken anhand der Kundennummer miteinander zu verknüpfen???? (es gibt ja nunmal 2 Connectionstrings) - Im DataDesigner habe ich nichts gefunden um die datenbanken zu verknüpfen....

Folgender aufbau:

Tabelle1 - FOXPRO - Kundenstammdaten wie z.b. Kdnr,name1,name2,strasse,plz....

Tabelle2 - MYSQL - Zusatzdaten zu den FOXPROKundenstammdaten verknüpft anhand der Kdnr..... hier werden weitere Daten Angegeben, die das WAWI Programm nicht unterstützt (z.b. Anzahl Mitarbeiter/mehrere Ansprechpartner)

diese Tabelle2 sollte aber auch gleich mit abgefragt werden.

wie kann ich das ganze realisieren - stehe auf dem schlauch.

unter access gab es die tolle möglichkeit, einfach verschiedene datenbanken mtieinander zu verbinden...

in c# scheint mir die möglichkeit nicht gegeben zu sein .-(((

hat mir jemand einen lösungsvorschlag (code,tutorial) wie ich so etwas realisieren kann?

Viele Grüße

Ronny

128 Beiträge seit 2004
vor 18 Jahren

Hallo Ronny,

Original von romu2000
das mit den beiden datasets funktioniert doch nicht so wie es mir vorstelle.

Wie sollte ich denn am besten vorgehen um die beiden datenbanken anhand der Kundennummer miteinander zu verknüpfen???? (es gibt ja nunmal 2 Connectionstrings) - Im DataDesigner habe ich nichts gefunden um die datenbanken zu verknüpfen....

Leider hast du meine Lösung nicht richtig gelesen und/oder verstanden. Okay, mag auch daran liegen, dass ich es schlecht formuliert habe. Es geht nicht darum, dass du die beiden Datenbanken miteinander verknüpfst, sondern eine Verbindung zwischen den beiden DataSets untereinander in C# also auf dem Client erzeugst.

diese Tabelle2 sollte aber auch gleich mit abgefragt werden.
wie kann ich das ganze realisieren - stehe auf dem schlauch.

Also, wenn ich dich richtig verstanden habe, dann hast du hier eine klassische 1:n-Relation. Durch einen Wechsel in deiner Mastertabelle (FoxPro) möchtest du weitere Informationen aus nun MySQL zu dem passenden Primärschlüssel abfragen, richtig?

unter access gab es die tolle möglichkeit, einfach verschiedene datenbanken mtieinander zu verbinden...

in c# scheint mir die möglichkeit nicht gegeben zu sein .-(((

Klar, weil C# keine Datenbank ist, dennoch geht es.
Bzgl. Verknüpfungen habe ich dir bereits den SQL Server genannt. In C# bzw. dem .NET Framework heißt das Schlüsselwort ADO.NET. Damit kannst du das gleiche produzieren.
Du kannst in ADO.NET innerhalb eines DataSets problemlos Relationen zwischen DataTables erzeugen.

Also, gehst du hin holst dir aus der ersten Verbindung (FoxPro) deine Haupttabelle und über eine zweite Verbindung die weiteren Informationen. Als nächstes kopierst du den DataTable des zweiten DataSets, wobei du auch direkt einen DataTable ziehen kannst in das DataSet der ersten Verbindung und erstellst dir ein Relationobjekt zwischen den beiden DataTables in eben diesem erweiterten DataSet.

Das ADO.NET DataSet ist in der Lage eine komplette Datenbank mit zig Tabellen und Relationen im Speicher deiner Anwendung abzubilden, daher kannst du hier auch Informationen aus unterschiedlichen Backends zusammenführen und nutzen.

Von MS Press gibt's einen umfangreichen Wälzer ausschliesslich zu ADO.NET. Onlinetutorial habe ich aktuell keins zur Hand, sollte sich aber per Google finden lassen. Ansonsten F1-Taste und in der .NET Hilfe nachschlagen.

Bis denne, JoKi

Bis denne, JoKi

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

3.728 Beiträge seit 2005
vor 18 Jahren

Original von romu2000
Nachdem ich jetzt mal gegooglet hatte und gesehen habe, dass ein SQL SERVER ja für lockere 10000+€ zu bekommen ist, wollte ich mal fragen was Ihr denn als alternative zu der Kostspieligen SQL SERVER Geschichte haltet, MYSQL einzusetzen.

Quatsch. Der SQL Server ist viel günstiger. Du brauchst ja nicht die Enterprise Server (die ist für Clustering). Die Standardversion kosten ca. 880 €.

R
romu2000 Themenstarter:in
291 Beiträge seit 2006
vor 18 Jahren
cool

hallo zusammen,

ersteinmal wieder vielen dank für die infos .-)

habe heute mit der geschäftsleitung gesprochen , der SQL Server geht klar .-)..wo bekommt man den standard sql server für 880€ ???

ich lese auch immer was von 5 clients....heisst das, dass ich mit gerade mal mit 5 worksations gleichzeitig drauf zugreifen darf????

was haltet ihr von der sql server 2005 express variante ???

@joki,

tausend dank für deine ausführliche anleitung , ich habe es jetzt hinbekommen...

vielen vielen dank .-)))

viele grüße

ronny

R
romu2000 Themenstarter:in
291 Beiträge seit 2006
vor 18 Jahren
Mist !!!

ahhhh mist,

ich hatte 2 tabellen aus einer connection verbunden 😦...

wenn ich 2 verschiedenartige tabellen so wie in dem bild verknüpfe (access und dataset1 = foxpro), kann ich ja mit dem abfragegenerator nicht wirklich eine abfrage generieren in denen die beiden tabellen zusammen vorkommen....

ist das denn irgendwie möglich oder muss ich einen INNER JOIN manuell "schreiben" ???

p.s. adressen21 = access
kdst=foxpro

Viele Grüße

Ronny

S
8.746 Beiträge seit 2005
vor 18 Jahren

Ein Hinweis: Die (inhaltliche) Verknüpfung verschiedener Datenbanken ist zwar lästig, aber möglich, grundsätzlich aber mit einem Problem behaftet: Transaktionen laufen nur innerhalb einer Connection. Will man Transaktionen über DB-Grenzen hinweg, muss man auf externe Transaktionsmanager ausweichen. Das sind bei .NET die EnterpriseServices.

Es kann natürlich im vorliegenden Fall sein, dass die Zugriffstrukturen eine Transaktionssicherung nicht erfordern, aber es sei mal als Problem genannt. Dabei spielt es grundsätzlich keine Rolle (im Detail schon), ob die DBs auf einem DB-Server oder getrennt hausieren. Vorraussetzung ist natürlich die entsprechende Unterstützung seitens der DB, was man VFP sicher ausschließen kann.

R
romu2000 Themenstarter:in
291 Beiträge seit 2006
vor 18 Jahren
keine möglichkeit ?

d.h. das ich mit der visual standard version keine möglichkeit habe die beiden DB´s zu bearbeiten?

Viele Grüße

Ronny

3.728 Beiträge seit 2005
vor 18 Jahren
Versionen

Auch in der aller größten Visual Studio Version hast Du das nicht. Es geht nicht, da es zwei verschiedene Datenbanksysteme sind. Du musst es in etwa so machen, wie ich auf der 1. Seite dieses Threads gepostet habe (1. Antwort von mir). Es ist auch gut so, dass es nicht geht. Man vermanscht nicht 2 verschiedene Anwendungen einfach so zusammen. 2 Anwendungen sollten immer über explizite Schnittstellen kommunizieren (z.B. Interfaces in C# oder XMLSchemas). In ein SAP System könntest Du auch nicht an der Applikation vorbei direkt auf die Datenbank zugreifen. Du müsstest Das über die BAPI (eine explizite Schnittstelle) tun. Access ist jedem Software Architekten ein Greul.

Für die Standard Edition des SQL Servers (die für ca. 880 €) brauchst Du natürlich CALs (Client Access Licenses). Die kannst Du aber einzeln dazukaufen. Eine einzelne User CAL wird ca. 150-180 € kosten. 5 CALS sind im Basisprodukt bereits enthalten. Am besten beziehst Du die SQL Server Lizenzen übers Microsoft Open License Programm (Aber nicht vergessen auch Installations-CDs mitzubestellen). Das ist günstiger, als Box-Produkte zu kaufen. Was auch logisch ist, da Du nur einen lizenzdatensatz kaufst und keine Verpackung, kein Handbuch etc.. Deshalb musst Du die Installations-CD extra dazukaufen (kostet ca. 35 €).

Ab 20 Benutzern würde ich Dir auf jeden Fall zum SQL Server Standard raten. Die Express Version ist nämlich etwas gedrosselt.

R
romu2000 Themenstarter:in
291 Beiträge seit 2006
vor 18 Jahren
danke

danke rainbird,

werde mich bezüglich des sql servers mal umschauen -

zur anderen sache :

so wie du auf seite eins geschrieben hattest , kann es aber nicht wirklich klappen, da die beziehung zu den beiden datenbanken ja in 2 unterschiedlichen connections nicht wirklich vorgenommen werden kann 😦

irgendeine idee ?

Viele Grüße

Ronny

128 Beiträge seit 2004
vor 18 Jahren

Mahlzeit,

Original von svenson
Vorraussetzung ist natürlich die entsprechende Unterstützung seitens der DB, was man VFP sicher ausschließen kann.

Kennst du überhaupt VFP?
Wie kommst du zu so einer Aussage?
Selbstverständlich gibt es in VFP Transaktionen. Oder was hast du mit deiner Aussage gemeint?

Bis denne, JoKi

Bis denne, JoKi

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

4.207 Beiträge seit 2003
vor 18 Jahren

Svenson sprach von externen Transaktionsmanagern, um eine Transaktion über mehrere Connections verteilen zu können ...

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

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

128 Beiträge seit 2004
vor 18 Jahren

Hi,

Original von Golo Haas
Svenson sprach von externen Transaktionsmanagern, um eine Transaktion über mehrere Connections verteilen zu können ...

Okay, dann habe ich es nicht verstanden. svenson bezog sich doch auf die EnterpriseServices des .NET Frameworks, oder habe ich da mißinterpretiert?

Bis denne, JoKi

Bis denne, JoKi

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

4.207 Beiträge seit 2003
vor 18 Jahren

So verstehe ich ihn auch.

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

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

128 Beiträge seit 2004
vor 18 Jahren

Mahlzeit,

Original von Golo Haas
So verstehe ich ihn auch.

Aha, und was hat das mit deiner ersten Aussage zu tun? Bzw. den 'Nichtfähigkeiten' von VFP? Wenn wir eh von .NET EnterpriseServices sprechen. Ich kapier's schlichtweg nicht, sorry. Wäre nett, wenn du die Zeit findest, um mich zu erhellen. Denn ich habe den Eindruck, dass hier von 3 verschiedenen Paar Schuhen gesprochen wird:

* VFP mit Transaktionen
* verteilte Transaktionen und
* .NET EnterpriseServices

Und die Aussage in meinem Verständnis lautete, dass man für Transaktionen über mehrere Connections die .NET EnterpriseServices nutzen muss.

Bis denne, JoKi

Bis denne, JoKi

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

R
romu2000 Themenstarter:in
291 Beiträge seit 2006
vor 18 Jahren
Linked SErver :-)

hallo mal wieder,

nachdem mir von JoKi ja die Lösung nahegelegt worden ist, auf MS SQL mit einem Verbindungsserver zuzugreifen (was auch klappt) stehe ich vor einem neuen problem.

Wenn ich eine normale abfrage im Visual Studio stelle die folgenden Code hat, erscheint eine Fehlermeldung:

SELECT     
           kdnr FROM         
           JUHU...kdst AS kdst_1

Die Fehlermeldung lautet:

Die "kdnr" -Spalte oder die benutzerdefinierte Funktion bzw. das benutzerdefinierte Aggregat "kdnr.toString" wurde nicht gefunden oder der Name ist mehrdeutig.

hat jemand eine idee?

Viele Grüße

Ronny

128 Beiträge seit 2004
vor 18 Jahren

Hallo Ronny,

Original von romu2000
Wenn ich eine normale abfrage im Visual Studio stelle die folgenden Code hat, erscheint eine Fehlermeldung:

SELECT       
           kdnr FROM           
           JUHU...kdst AS kdst_1  

Die Fehlermeldung lautet:

Die "kdnr" -Spalte oder die benutzerdefinierte Funktion bzw. das benutzerdefinierte Aggregat "kdnr.toString" wurde nicht gefunden oder der Name ist mehrdeutig.

hat jemand eine idee?

Ich nehme mal an, dass das Feld kdnr in mehreren Tabellen vorliegt. Daher musst du den Tabellenpräfix in der Fieldlist deines Selects angeben:

Select kdst_1.kdnr From Juhu...kdst As kdst_1

Es sei denn, deine Tabelle kdst hat überhaupt keine Spalte namens kdnr... 8)

Bis denne, JoKi

Bis denne, JoKi

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

R
romu2000 Themenstarter:in
291 Beiträge seit 2006
vor 18 Jahren
hmmt

hallo JoKi .-)

funktioniert leider so auch nicht, da der DataDesigner wohl seine eigenen regeln hat .-)

ich habe mich jetzt eh dazu entschlossen, alles auf FOXPRO zu machen....das vereinfacht wohl so einiges...

die erste tabelle habe ich schon ins foxproformat importiert und stehe schon vor dem nächsten problem ...sie neuer thread .-)

danke für deine hilfe

p.s. ich habe auch gemerkt, das bei normalen abfragen mit dem verbindungsserver verbunden mit foxpro die performance extrem nachlässt....

die abfrage funktioniert nähmlich soweit, dass wenn ich kdnr nicht anzeigen lasse, alles funktioniert .-(

macht wohl irgendwie das tostring probleme.

habe dann mal ne accessdatei in foxpro convertiert und siehe da, das ganze ist ungefähr 80% schneller als die lösung mit MSSQL und FOXPRO 🙂

viele grüße

ronny

3.728 Beiträge seit 2005
vor 18 Jahren

Original von JoKi

FoxPro ist tot!
*gäääähn* - Sorry, aber der Spruch hält sich nun seit 10+ Jahren und das Produkt ist immer noch auf dem Markt und es sicherlich auch noch bis mindestens 2014 bleiben.

Deine persönliche Aversion gegen VFP in Ehren, aber selbst SQL Server ist nicht immer die beste Lösung - nur scheint mir hier der Eindruck zu sein, dass du dir dessen in keinster Weise bewusst ist.

Mal was anderes: Was hat deine platte Aussage zu VFP eigentlich mit der Problemstellung hier in diesem Thread zu tun? Es wäre sicherlich wesentlich hilfreicher, wenn du Lösungen statt Meinugen posten würdest. Aber hey, ich möchte dir nichts vorschreiben - in deiner Community.

Auch wenn ich jetzt Öl ins Feuer gieße:

FoxPro wird nicht mehr weiterentwickelt. Es wird zwar noch bis einschlißlich 2014 supportet, was aber nur heißt, dass man sich um Sicherheitslücken und evtl. auftretende Bugs kümmert. Technologieen die nicht mehr weiterentwickelt werden sind tot. Das ist einfach so. Es ist also kein platte Aussage von Golo, sondern die Realität.

Foxpro wird das gleiche Schicksal erleiden wie Visual Basic 6.0, Visual Basic for Applications, Visual InterDev 6.0, ... Das sind alles auch Entwicklungssysteme. Auch wenn momentan noch viele Anwendungen auf dem Markt damit entwicklet worden sind und vorerst noch weiter damit entwickelt werden (weil eine Migration nicht immer ohne weiteres möglich ist und vor allem auch das Know-How für die neuen Technologieen bei den Entwicklern fehlt), sind die Technologieen trotzdem jetzt schon tot. Wenn diese Anwendungen nicht innerhalb der nächsten fünf Jahre auf die aktuelle Technologie portiert/migriert werden, werden auch die Anwendungen tot sein.

Auch wenn die Anforderungen eines Projekts für Foxpro sprechen würden, sollte man es trotzdem nicht einsetzen, da es den langfristigen Erfolg des Projekts beeinträchtigt, wenn man als Fundament auf tote Technologieen setzt.

128 Beiträge seit 2004
vor 18 Jahren

Hallo,

Original von Rainbird
Auch wenn ich jetzt Öl ins Feuer gieße:

FoxPro wird nicht mehr weiterentwickelt. Es wird zwar noch bis einschlißlich 2014 supportet, was aber nur heißt, dass man sich um Sicherheitslücken und evtl. auftretende Bugs kümmert. Technologieen die nicht mehr weiterentwickelt werden sind tot. Das ist einfach so. Es ist also kein platte Aussage von Golo, sondern die Realität.

Die Aussage ist sowohl korrekt wie nicht korrekt. VFP wird sehr wohl noch weiterentwickelt. Dazu gibt es seit Monaten eine entsprechende Roadmap. Es wird eine Zusatzkomponente für VFP 9.0 geben - aktuell Sedna - welche die Interop mit dem .NET Framework und weiteren Schnittstellen, etwa von Vista und Longhorn Server offerieren wird.

Dennoch sehe ich die Situation als realistisch an, und arbeite selbst interessiert mit C#. Schliesslich möchte man ja auf dem aktuellen Stand der Entwicklung bleiben.

Foxpro wird das gleiche Schicksal erleiden...

Mag sein, who knows... Vielleicht bereits schon morgen, vielleicht erst in 5 Jahren.

Und einem professionellen Entwickler ist die Syntax einer Programmiersprache eigentlich schnuppe, oder? 😁

Bis denne, JoKi

Bis denne, JoKi

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