Das Forentreffen 2018 findet am 20./21. April in Dresden statt. Weitere Infos hier
Zur Homepage des Deutschsprachige Xbase-Entwickler e. V.
Xbase++-Wiki des Deutschsprachige Xbase-Entwickler e. V.

Probleme mit SqlExpress - logisches Feld/Ascii-Konvertierung

SQL Express von Boris Borzic

Moderator: Moderatoren

Antworten
Erich60
Rookie
Rookie
Beiträge: 2
Registriert: Di, 16. Nov 2010 23:51

Probleme mit SqlExpress - logisches Feld/Ascii-Konvertierung

Beitrag von Erich60 » Sa, 20. Nov 2010 23:55

Habe die Testversion (neueste Version) von SqlExpress und habe Probleme mit logischen Feldern und der (automatischen) Ascii-Konvertierung.
Setze MySql 5.1 und 5.5 ein. Probleme sind gleich.

Hier die Sql-Syntax, die über Workbench gestartet wurde:

create Table test.test (name varchar(30),Aktiv Bit(1), primary key (name));
insert Test.test (Name,Aktiv) values ("ÄÖÜöäÜ Test",1);
insert Test.test (Name,Aktiv) values ("Test öäüÖÄÜ",0);

Dann habe ich das Programm SqlBro.prg nur so modifiziert, dass auf die Sql-Tabelle zugegriffen und angezeigt wird.

Das Feld "Aktiv" wird in beiden Fällen mit FALSE (.F.) auch im DataArea von oCursor ausgegeben. Die automatische Ascii-Konvertierung funktioniert auch nicht. Mit einer User-Funktion bekomme ich das in den Griff, sollte aber nicht sein.
Über die normale Alaska-Odbc bekomme ich auch die Konvertierung und die Ausgabe der Logischen Felder ist auch korrekt.

DbeSys enthält:
PROCEDURE DbeSys()
set collation to ASCII
Return

In der normalen Alaska-Odbc habe ich allerdings das Problem, dass bei varChar-Feldern öfters der rechte Teil abgeschnitten wird. Anscheinend wird die Länge des Feldes aus dem ersten Datensatz ermittelt. Gibt es bei Tabellen varChar(n)-Felder und Char(1)-Felder bekomme ich den folgenden XppError.log, sobald auf das char(1)-Feld zugegriffen wird.
oError:description : Fehler beim Lesen
oError:filename :
oError:genCode : 73
oError:operation : KZ_INV

wer kennt bzw. hat/hatte diese Probleme ?? besser noch die Lösung

Nachtrag: benutze xBase 1.90.331 + xbTools

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 13764
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Probleme mit SqlExpress - logisches Feld/Ascii-Konvertie

Beitrag von brandelh » So, 21. Nov 2010 2:10

Hi,

ich musste auf den älteren MySQL ODBC Treiber, wegen Umlautproblemen.
Möglicherweise kann man das aber auch einstellen. Hierzu solltest du aus http://www.xbwin.com nachfragen,
dort gibt es extra eine newsgroup für die Produkte von Boris - oder natürlich direkt bei Ihm.
Gruß
Hubert

Erich60
Rookie
Rookie
Beiträge: 2
Registriert: Di, 16. Nov 2010 23:51

Re: Probleme mit SqlExpress - logisches Feld/Ascii-Konvertie

Beitrag von Erich60 » Mi, 01. Dez 2010 13:37

Erich60 hat geschrieben:habe Probleme mit logischen Feldern
ist ein BUG in SqlExpress, wurde korrigiert. (neue SqlExpress-Version)
Erich60 hat geschrieben: der (automatischen) Ascii-Konvertierung.
wird wohl nicht von SqlExpress unterstützt.
Mit "SET CHARSET TO ANSI " wird die Anzeige zwar korrekt, schafft aber dann die Konvertierungsprobleme bei DBF-Files, die eine ASCII-Codierung enthalten.

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 13764
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Probleme mit SqlExpress - logisches Feld/Ascii-Konvertie

Beitrag von brandelh » Do, 02. Dez 2010 9:51

Erich60 hat geschrieben:Mit "SET CHARSET TO ANSI " wird die Anzeige zwar korrekt, schafft aber dann die Konvertierungsprobleme bei DBF-Files, die eine ASCII-Codierung enthalten.
Laut Handbuch und meinen Erfahrungen bedient ein ANSI Programm eine DBFNTX Datei automatisch fehlerfrei mit OEM Zeichen.
Also keinesfalls zusätzlich ConvToOemCP() nutzen. Ob es immer ein "passendes" Zeichen gibt weiß ich jetzt aber nicht.
Gruß
Hubert

Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 6797
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Kontaktdaten:

Re: Probleme mit SqlExpress - logisches Feld/Ascii-Konvertie

Beitrag von Tom » Do, 02. Dez 2010 10:45

SET CHARSET wirkt sich auf konstante Daten (z.B. Texte im Source) und auf alle Alaska-DBEs aus. Außerdem wird für die Active-X-Schnittstelle (inzwischen) sauber konvertiert, denn die meisten (eigentlich alle) AX-Komponenten wollen ANSI. Für alles andere, vor allem die Nutzung von Fremd-DLLs, muss mit ConvToAnsiCP() und ConvToOemCP() vor und zurück konvertiert werden. Wenn ich z.B. List & Label als Active-X-Komponente nutze, kann ich auf Konvertierungen verzichten, aber in der DLL-Version (die ich tatsächlich nutze) muss ich meine OEM-Daten (das gilt NUR für Texte!) mit ConvToAnsiCP() an den Formulargenerator übermitteln. Soweit ich mich erinnere, gilt das auch für SQLExpress. Im normalen Zeichensatzbereich (Ziffern, Buchstaben, Satzzeichen) ergibt die Vor-und-Zurückkonvertierung immer dasselbe, aber sobald man sich in Sonderzeichenbereiche begibt, wird es schwierig. Die Unterschiede kann man sich z.B. in der Windows-Zeichentabelle ansehen.
Herzlich,
Tom

Antworten