none
Problem mit ODBC Native Client und VFP RRS feed

  • Frage

  • Hallo Leute!
     
    Wir greifen per ODBC auf den MS-SQL Server zu. Dort wurden bisher alle unsere Memos mit dem Datentyp Text abgelegt.
    Da es div. kleinere Probleme mit den Datentyp gibt und da er schon seit geraumer Zeit ab gekündigt ist, haben wir nun begonnen
    unsere APP auf varchar(max) umzustellen.
    Nur leider scheint es da irgendwo einen Bug zu geben:
    Nutzt man den SQL Native Client und erzeugt einen View auf eine Tabelle mit einem varchar(max) Feld, dann gibt es beim öffnen des Views folgenden Fehler: DataType property for field 'xxxmemo' is invalid.      1544.
     
    Erzeuge ich mit SQL Pass Through (sqlexec) einen Cursor von der gleichen Tabelle, so hat der Cursor kein Memo, sonder ein c(0) Feld!
     
    Nach einigen googeln soll die Lösung sein, den 11 Jahre alten SQL Server ODBC Treiber zu benutzten. Diesen haben wir aber schon lange abgesetzt, da er bei Vielen unserer Kunden zu div. Problemen geführt hat.
     
    Hat jemand noch eine Idee?
     
    Den View kann ich mittels dbsetprop("xxxView.xxxmemo","field","DataType", "M(0)") umbiegen, dann scheint alles zu funktionieren. Aber wie kann ich das für einen Cursor machen?
     
    grüße
    Jörg Schneider
     

    Jörg Schneider
    Montag, 5. September 2011 11:49

Alle Antworten

  • Muss es wirklich ein varchar(max) sein?

    Wenn Du einen varchar(8000) nimmst, dann biegt er das korrekt in ein Memo-Feld um, wenn ich mich richtig erinnere.

    Alternativ als Workaround kannst Du einen CONVERT(text, feldname) im SQL-Select einbauen.

    Montag, 5. September 2011 13:40
  • Wir hatten auch genau das Problem und uns für den SQL Server ODBC Treiber entschieden.

    11 Jahre Alter stimmt auch nicht. Wir nutzen eine Version, die unter XP z.B. erst mit XP SP3 reinkommt, und das ist nicht 11 Jahre alt. Es mag sein, daß es vor 11 Jahren mal die erste Version des Treibers gab, aber das heißt ja nicht, daß es die einzige ist. Aktuell verbinde ich mich damit zu einem SQL2008 R2 Server, allerdings nutzen wir noch keine neuen Feldtypen. Das müßte man mal probieren, mit 2005 ging jedenfalls auch alles, was wir nutzten: uniqueidentifier, bit, int, int identity, numeric, float, datetime, char, varchar und eben varchar(MAX). Varbinary(Max) ginge auch, haben wir aber nicht im Einsatz, mehr als die o.g. Feldtypen braucht man doch gar nicht. Die Datenbank ist außerem eingestellt auf Latin1 Zeichensatz. Unicode, sprich nchar, nvarchar, nvarchar(MAX) gingen auch, müßten aber dann in VFP automatisch oder manuell in ANSI gewandelt werden, oder man bräuchte Unicode Controls.

    Also, vielleicht mal die neueste Version davon rauskramen und probieren.

    Abgesehen davon, mit SQL Native Client hast Du mit SQLExec() eben verloren, allerdings bietet neben dem Remoteview auch der Cursoradapter an, ein Cursorschema vorzugeben. Eine Nutzung des CA als SQLExec-Ersatz ist auch denkbar, letztlich nutzt Du die SelectCmd Eigenschaft, statt dasselbe SQL per SQLExec() abzusetzen. Habe ich aber nicht probiert, wäre mir persönlich zu einschränkend, wenn auch schon besser als Remoteviews, ich nutze eine Mischung as CA für updatebare ergebnisse und SQLExec() für dynamischeres, u.a. auch Datenbankupdateskripte.

    Tschüß, Olaf.


    Montag, 5. September 2011 22:52
  • Hi,

    gestern hat Andrew McNeill einen interessanten Beitrag zum Thema ODBC und OLEDB gepostet...

    http://akselsoft.blogspot.com/2011/09/glad-we-spent-all-that-time-on-ole-db.html

    JM2C ;)


    Gruss / Best regards -Tom 010101100100011001010000011110000101001001101111011000110110101101110011
    Dienstag, 6. September 2011 06:09
  • Hi Olaf!
     
    also der "alte" SQL Server Treiber ist für uns leider keine Alternative, da wir mit ihm div. Probleme hatten, die mit dem Native Client behoben waren.
    Wir prüfen jetzt mal ob und wie wir unsere APP (also genauer unser internes Zugriffsobjekt welches wir zum glück haben ;) ) für SQL Passthrough auf Cursoradapter anpassen können.
    Mal gespannt was da raus kommt.
     
    Grüße
    Jörg Schneider
     
    Am 06.09.2011 00:52, schrieb Olaf Doschke:
    > Wir hatten auch genau das Problem und uns für den SQL Server ODBC Treiber entschieden.
    >
    > 11 Jahre Alter stimmt auch nicht. Wir nutzen eine Version, die unter XP z.B. erst mit XP SP3 reinkommt, und das ist nicht 11 Jahre alt. Es mag sein, daß es vor 11 Jahren mal die erste Version des Treibers gab, aber das heißt ja nicht, daß es die einzige ist. Aktuell verbinde ich mich damit zu einem SQL2008 R2 Server, allerdings nutzen wir noch keine neuen Feldtypen. Das müßte man mal probieren, mit 2005 ging jedenfalls auch alles, was wir nutzten: uniqueidentifier, bit, int, int identity, numeric, float, datetime, char, varchar und eben varchar(MAX). Varbinary(Max) ginge auch, haben wir aber nicht im Einsatz, mehr als die o.g. Feldtypen braucht man doch gar nicht. Die Datenbank ist außerem eingestellt auf Latin1 Zeichensatz. Unicode, sprich nchar, nvarchar, nvarchar(MAX) gingen auch, müßten aber dann in VFP automatisch oder manuell in ANSI gewandelt werden, oder man bräuchte Unicode Controls.
    >
    > Also, vielleicht mal die neueste Version davon rauskramen und probieren.
    >
    > Abgesehen davon, mit SQL Native Client hast Du mit SQLExec() eben verloren, allerdings bietet neben dem Remoteview auch der Cursoradapter an, ein Cursorschema vorzugeben. Eine Nutzung des CA als SQLExec-Ersatz ist auch denkbar, letztlich nutzt Du die SelectCmd Eigenschaft, statt dasselbe SQL per SQLExec() abzusetzen. Habe ich aber nicht probiert, wäre mir persönlich zu einschränkend, wenn auch schon besser als Remoteviews, ich nutze eine Mischung as CA für updatebare ergebnisse und SQLExec() für dynamischeres, u.a. auch Datenbankupdateskripte.
    >
    > Tschüß, Olaf.
    >
    >
     
     

    Jörg Schneider
    Dienstag, 6. September 2011 08:17
  • Moin, moin Was ist mit CURSORSETPROP("MapBinary", .T. 0) , das gilt doch laut Hilfe für die gesamte Session , alle Cursor, SPT, RV,... Gruesse tom
    Freitag, 9. September 2011 09:12
  • Moin!
     
    Jo, leider nicht für varchar(max) felder. Die bleiben schön leer :-/
     
    trotzdem Danke
     Am 09.09.2011 11:12, schrieb tom knauf:
    > Moin, moin Was ist mit CURSORSETPROP("MapBinary", .T. 0) , das gilt doch laut Hilfe für die gesamte Session , alle Cursor, SPT, RV,... Gruesse tom
     
     

    Jörg Schneider
    Freitag, 9. September 2011 11:34
  • Moin, moin weil es noch auf ungelöst steht : vc ist ein Varcharfeld mit einem PDF als Inhalt (filetostr()) nx = SQLEXEC(nh,"Select *, Cast(vc as varbinary(max)) as vctest from testvc") oder nx = SQLEXEC(nh,"Select *, convert(text,vc) as vct from testvc") Die erste Lösung ist wahrscheinlich besser, text soll man ja vermeiden VFP macht ein memo draus, Inhalt identisch mit einem identisch gefüllten varbinary(max) HTH Grüße tom
    Mittwoch, 14. September 2011 07:03
  • Wir machen folgendes: wenn wir mit Buildern arbeiten, benutzen wir im Design den "Alten" ODBC Treiber und stellen anschließend, nachdem das Schema richtig erstellt wurde auf UseCursorSchema. Wenn wir programmatisch einen Cursoradapter erstellen, laden wir zunächst ohne Daten, dabei gibt es noch keinen Fehler mit dem C(0). Dann suchen wir im Schema nach dem C(0) und ersetzen es durch M und setzen wieder UseCursorSchema auf true.

    Dann erst laden wir die Daten. So können wir im Produktionsbetrieb den ansonsten besseren und performanteren Native Client benutzen

    Hoffe das hilft weiter.

    Lieben Gruß 

    Kirsten


    Dienstag, 2. Juli 2019 16:02
  • Vielleicht hätte ich damals nochmal reagieren sollen? Ich weiß nicht, meine aktuellen Installationen sind auch nicht auf dem allerletzten Stand, aber es ist falsch anzunehmen Microsoft entwickelt nur eine Treiberserie.

    Ich pflege z,Zt, allerdings eine Anwendung, bei der die Benutzer DSN auch auf SQL Server Native Client 11 basiert und mit Remote Views arbeitet. Da ist das Cursorschema über Viewdefinitionen vorgegeben, genauso geht das mit Cursoradapter. Wenn das einmal richtiggestellt ist, ist das Thema auch gegessen.

    Tschüß, Olaf.

    Dienstag, 2. Juli 2019 20:41