Laden...

Aus C# über Dapper Daten in eine Foxpro DB eintragen erzeugt leeren Eintrag

Erstellt von susisorglos vor 6 Jahren Letzter Beitrag vor 6 Jahren 2.057 Views
susisorglos Themenstarter:in
43 Beiträge seit 2008
vor 6 Jahren
Aus C# über Dapper Daten in eine Foxpro DB eintragen erzeugt leeren Eintrag

verwendetes Datenbanksystem: <Foxpro 9.0 DB>

Liebe Community,

sicher erkennt Ihr den Fehler auf Anhieb?!

Ich möchte aus einer C# Anwendung unter Dapper Daten in eine Foxpro DB eintragen.
Die Daten werden satzweise geschrieben.
Hier habe ich nur ein Feld BUCHSTABEN dargestellt.



DynamicParameters param = new DynamicParameters();
string text = "Anwender40";
param.Add("@buchstaben", text, dbType: DbType.String, direction: ParameterDirection.Input, size: 10);
int result = 0;
result = con.Execute("setanwenderBuchstabe", param, commandType: CommandType.StoredProcedure);

Foxpro Tabelle foxBuchstabe
das Feld BUCHSTABEN ist als Buchstabe deklariert.

SP

PROCEDURE setanwenderBuchstabe 
LPARAMETERS buchstaben;

USE foxBuchstabe

INSERT INTO foxBuchstabe.dbf(BUCHSTABEN) VALUES (buchstaben)

\* Tabelle öffnen
\* APPEND BLANK
\* REPLACE BUCHSTABEN WITH &quot;Anwender52&quot; &amp;&amp;&lt;-- das klappt
\* REPLACE BUCHSTABEN WITH buchstaben &amp;&amp;&lt;-- erzeugt einen leeren Eintrag
RETURN

Ob INSERT INTO bzw. REPLACE BUCHSTABEN WITH, der Eintrag ist ein leeres Feld.
Was mache ich falsch?

Ich sage für jede Kritik -
Herzlichen Dank.

VS 2017 Community

16.806 Beiträge seit 2008
vor 6 Jahren

Bist Du Dir sicher, dass der Provider hinter Dapper wirklich auch SPs von Foxpro voll unterstützt?

susisorglos Themenstarter:in
43 Beiträge seit 2008
vor 6 Jahren

@Abt

Gute Frage.
Wie kann ich das 'voll' prüfen?

Auf eine andere FoxPro Datenbank greife ich bereits mit C#, Dapper und SP erfolgreich lesend zu.

Es ist mein erster Schreibversuch.
Bei satzweisem Zugriff und INSERT INTO in der SP werden kurioser Weise einige Variablen und zwar immer dieselben Felder übernommen, jedoch eben nicht alle.

Ich habe deshalb den Datensatz in die einzelnen DatenTypen zerlegt.

Deshalb - nochmal die Frage,
wie kann ich prüfen ob der Provider hinter Dapper wirklich auch SPs von Foxpro voll unterstützt?

Vielen Dank fürs Mitdenken!

VS 2017 Community

susisorglos Themenstarter:in
43 Beiträge seit 2008
vor 6 Jahren

@Abt

Vielen Dank für die neue Denkrichtung.

https://msdn.microsoft.com/en-us/library/0xzsac67(v=vs.90).aspx

Note Stored Procedure Support

'When you use Visual FoxPro OLE DB Provider as a SQL Server-linked server, only queries are supported.
The Visual FoxPro OLE DB Provider does not support update, insert, or delete operations through a linked server.'

Ich arbeite mit VFPOLEDB1.

Gibt es Alternativen?

LG susi

VS 2017 Community

16.806 Beiträge seit 2008
vor 6 Jahren

Ja: auf FoxPro verzichten und was zeitgemäß|ordentliches nehmen.
FoxPro ist seit über 10 Jahren abgekündigt.

susisorglos Themenstarter:in
43 Beiträge seit 2008
vor 6 Jahren

@Abt

Der Wechsel ist schon Chefsache, der Trend ist gesetzt.
Hier geht es um das Ausloten von Grenzen und Möglichkeiten.

Vielen Dank, fürs Mitdenken.

VS 2017 Community

16.806 Beiträge seit 2008
vor 6 Jahren

Hast ja die Grenzen nun gefunden.

30 Beiträge seit 2007
vor 6 Jahren

Hallo Susi,

der Fehler liegt nicht am OleDb-treiber sondern an einer fehlerhaften Stored-Procedure.

Du hast in der Procedure einen Parameter deklariert, der genau so heißt wie ein Tabellenfeld. In FoxPro hat in einem solchen Fall der Inhalt des Tabellenfeldes Vorrang und blendet den Parameter aus. In deinem Fall heißt das dann, du fügst einen neuen Datensatz zur Tabelle hinzu und setzt den Wert des Feldes BUCHSTABEN auf den Wert des Feldes BUCHSTABEN, ergo leere Zeichenfolge.

Zur Korrektur musst du nur den Namen des Parameters der Stored-Procedure ändern und dann funktioniert es auch.


PROCEDURE setanwenderBuchstabe 
LPARAMETERS buchstaben_neu

USE foxBuchstabe

INSERT INTO foxBuchstabe.dbf(BUCHSTABEN) VALUES (buchstaben_neu)

@Abt
Du hast selbstverständlich Recht, Foxpro ist seit langem abgekündigt und man ist gut beraten, sich nach Alternativen umzuschauen. Oft hat man aber große, gewachsene Anwendungen, die man eben nicht mal so eben umstellen kann, bzw. die man während der Umstellungsphase weiterhin pflegen und erweitern muss. Und in diesem Zusammenhang ist es durchaus legitim, Erweiterungen in einer modernen Entwicklungsumgebung vorzunehmen, die auf die FoxPro-Datenbanken zugreifen.

Viele Grüße

Jens

16.806 Beiträge seit 2008
vor 6 Jahren

Oft hat man aber große, gewachsene Anwendungen, die man eben nicht mal so eben umstellen kann, bzw. die man während der Umstellungsphase weiterhin pflegen und erweitern muss. Und in diesem Zusammenhang ist es durchaus legitim, Erweiterungen in einer modernen Entwicklungsumgebung vorzunehmen, die auf die FoxPro-Datenbanken zugreifen.

Prinzipiell gebe ich Dir recht; aber nicht, wenn wir hier von einem Abkündigungszeitraum von über 10 Jahren sprechen 😉

susisorglos Themenstarter:in
43 Beiträge seit 2008
vor 6 Jahren

@jbrand
Vielen Dank. Du hast mir grandios geholfen.
Ich habe dich im Quelltext verewigt.
Die Anwendung läuft nun mit deiner Hilfe.

susi

VS 2017 Community