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 "Anwender52" &&<-- das klappt
\* REPLACE BUCHSTABEN WITH buchstaben &&<-- 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
Bist Du Dir sicher, dass der Provider hinter Dapper wirklich auch SPs von Foxpro voll unterstützt?
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
@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
@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
Ja: auf FoxPro verzichten und was zeitgemäß|ordentliches nehmen.
FoxPro ist seit über 10 Jahren abgekündigt.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
@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
Hast ja die Grenzen nun gefunden.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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
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 😉
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
@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