XMLSerializer: Verschachtelte XML-Dateien mit Arrays?

**Elvis**

Hab' mir doch etwas Zeit gelassen.
Ich habe ein Archiv mit der Klasse und 2 Kompilaten (1.1 und 2.0) angehängt.

Falls du es selbst kompilieren willst:
Als Compiler empfehle ich dir die Mono version (

hier ganz unten, da sie einfach als tar ball kommt, den du nur irgendwohin entpacken musst.
Kompiliert wird für jeweils eine bestimmte .Net Version so:

markieren

Code:

			chrome.exe SampleLib.chrome /frameworkversion=v1.1.4322 out=1.1

chrome.exe SampleLib.chrome /frameworkversion=v2.0.50727 out=2.0

**Alexander**

Cool Danke, Robert!

Ich werde mir das nachher zu Hause mal in Ruhe anschauen.

Nachtrag:
Im Prinzip hatte ich es so eigentlich auch. Nur konnte Delphi merkwürdiger Weise nicht von IXmlSerializable ableiten

.
Ich werde es nachher noch mal probieren. Oder noch besser lasse es einfach sein und nehme für so was wirklich den Chrome- oder C#-Compiler

.

**Elvis**

Zitat von Alexander:

Cool Danke, Robert!

Kein Problem.

Zitat:

Oder noch besser lasse es einfach sein und nehme für so was wirklich den Chrome- oder C#-Compiler

.

Kann ich nur empfehlen...

**Alexander**

Ich habe jetzt einfach mal zum Testen deine fertige Lib verwendet.
Und es scheint zur Hälfte zu funktionieren

.
In der XML-Datei soll ein SQL-Statement abgespeichert werden. Dieses wird gleich am Anfang an eine (Fremd-) Komponente (Win32, ActiveX) weitergegeben. Theoretisch mit dem CDATA-Abschnitt ja kein Problem.
Bisher habe ich zum Testen ohne CDATA gearbeitet - hat mit der Komponente funktioniert. Um die gleichen SQL-Statements habe ich nun ein <![CDATA[ und ein ]]> geschrieben.
Dann das Object (CData statt String) angepasst und *wuppdi* hätte es funktionieren müssen.

Die verwendete Komponente sagt mir den folgenden Fehler:

Zitat:

Die SELECT-Anweisung schließt ein reserviertes Wort oder einen Argumentnamen ein, das/der falsch, mit falscher Zeichensetzung oder überhaupt nicht eingegeben wurde.
[ODBC Error] SQLSTATE=37000]

Das verwendete Statement ist eigentlich richtig (aus der XML eingelesen):

markieren

SQL-Code:

			---------------------------

---------------------------

 SELECT Artikel.[Artikel-Nr], Artikel.Artikelname, Artikel.[Lieferanten-Nr], Artikel.Lagerbestand FROM  Artikel ORDER BY  Artikel.[Artikel-Nr] where (Artikel.[Artikel-Nr] between 1 and 10) 

---------------------------

OK   

---------------------------

Genau dieses Statement hat zu vor funktioniert.

Kann es sein, dass die Komponente irgendwelche Codierungen verwechselt? Hast du eine Idee, woran das liegen könnte?

Besten Dank nochmals,
Alexander

**Elvis**

Zitat von Alexander:

Ich habe jetzt einfach mal zum Testen deine fertige Lib verwendet.

Der solltest du aber noch deinen Namespace[1] verpassen und sie dann neu kompostieren. ClassLib1 sieht komisch aus.

Zitat:

Kann es sein, dass die Komponente irgendwelche Codierungen verwechselt? Hast du eine Idee, woran das liegen könnte?

Ohne den Code, mit dem du es an die Komponente übergeben hast, wird das etwas schwer.
Sehr dumm ist es, wenn die Komponente ein Object schluckt und dann einfach anhand des Typen irgendwas friemelt. Deshalb würde ich einen Cast auf String empfehlen.
Außerdem ist es nicht dumm der XML Datei ein Unicode-Format zu geben um Konvertierungsprobleme gleich von Anfang an auszuschließen.

Es ist leider nicht möglich den inneren Text öffentlich zugänglich zu machen ohne Inkonsistenzen zu riskieren.
CData muss als primitiver Typ auftreten, auch wenn es eigentlich nur ein Wrapper um einen String ist.

btw: Diese eckigen Klammern gibt es eigentlich nur in den beiden komischen Accessversionen, die Microsoft DBMS nennt: Dem serverbasierten Access namens SqlServer und dem clientbasierten Access namens Jet/Access.

Bei einen richtigen/normalen DBMS werden Bezeichner, die gegen die Regeln normaler Bezeichner des DBMS verstoßen, in Anführungszeichen ( #34 ) eingeschlossen. Wobei die Bezeichner dann auch case sensitive sind!

[1]der Teil vor dem letzten Punkt in deinen Unitnamen, DfN-Namespaces sind, höflich ausgedrückt, komisch

**Alexander**

Zitat von Elvis:

Zitat von Alexander:

Ich habe jetzt einfach mal zum Testen deine fertige Lib verwendet.

Der solltest du aber noch deinen Namespace[1] verpassen und sie dann neu kompostieren. ClassLib1 sieht komisch aus.

Na klar, war ja nur zum Testen.

Zitat:

Kann es sein, dass die Komponente irgendwelche Codierungen verwechselt? Hast du eine Idee, woran das liegen könnte?

Ohne den Code, mit dem du es an die Komponente übergeben hast, wird das etwas schwer.
Sehr dumm ist es, wenn die Komponente ein Object schluckt und dann einfach anhand des Typen irgendwas friemelt. Deshalb würde ich einen Cast auf String empfehlen.

Ist eigentlich zumindest, nach dem was Delphi anzeigt, ein string. (Gibt es eigentlich einen Unterschied zwischen string und String? Oder wird das string auf String gemappt, oder umgekehrt?)

Zitat:

Außerdem ist es nicht dumm der XML Datei ein Unicode-Format zu geben um Konvertierungsprobleme gleich von Anfang an auszuschließen.

Ist ein Utf-8-Format (<?xml version="1.0" encoding="utf-8"?>)

Zitat:

Es ist leider nicht möglich den inneren Text öffentlich zugänglich zu machen ohne Inkonsistenzen zu riskieren.
CData muss als primitiver Typ auftreten, auch wenn es eigentlich nur ein Wrapper um einen String ist.

btw: Diese eckigen Klammern gibt es eigentlich nur in den beiden komischen Accessversionen, die Microsoft DBMS nennt: Dem serverbasierten Access namens SqlServer und dem clientbasierten Access namens Jet/Access.

Bei einen richtigen/normalen DBMS werden Bezeichner, die gegen die Regeln normaler Bezeichner des DBMS verstoßen, in Anführungszeichen ( #34 ) eingeschlossen. Wobei die Bezeichner dann auch case sensitive sind!

Jupp, ist Access

. Aber auch nur weil ich da die nwind Datenbank als Testdatenbank nehme. Ich muss die Komponente auch noch mal zu ADO.NET überreden

.

Nachtrag:
Zum Source: Die Lade und Speicher Methode und ein Test-Object stehen ja oben schon.
Und so setze ich einfach das SQL-Statement:
Cube.DCRecordSource := aStatement.Sql; Das war's im Prinzip.

**Elvis**

Zitat von Alexander:

st eigentlich zumindest, nach dem was Delphi anzeigt, ein string.

Dann sollte es keine Probleme geben. CData kann sich implizit in einen String wandeln indem es einfach Text zurückgibt.

Zitat:

Gibt es eigentlich einen Unterschied zwischen string und String?

Ja gibt es, zumindest syntaktisch. In Delphi.Net kannst du keine Member von String benutzen, außer du nimmst einen typecast auf System.String, bzw. deklarierst ihn so.

Zitat:

Oder wird das string auf String gemappt, oder umgekehrt?

Da kennt wohl einer Reflector noch nicht?

Wirkliche Klarheit wird dir nur der Debugger liefern können. Einfach mal schauen, was in CData drin steht.
Da CData ToString überschreibt sollte der Inhalt zu sehen sein ohne es aufklappen zu müssen.

**Alexander**

Ich habe es jetzt noch mal mit dem Chrome-Compiler neu kompiliert (nun auch mit nem ordentlichen Namespace).

Zitat von Elvis:

Zitat von Alexander:

st eigentlich zumindest, nach dem was Delphi anzeigt, ein string.

Dann sollte es keine Probleme geben. CData kann sich implizit in einen String wandeln indem es einfach Text zurückgibt.

Das habe ich mir ja auch gedacht. Es gibt einfach keinen Unterschied. Dennoch meckert die Komponente.

Zitat:

Gibt es eigentlich einen Unterschied zwischen string und String?

Ja gibt es, zumindest syntaktisch. In Delphi.Net kannst du keine Member von String benutzen, außer du nimmst einen typecast auf System.String, bzw. deklarierst ihn so.

Zitat:

Oder wird das string auf String gemappt, oder umgekehrt?

Da kennt wohl einer Reflector noch nicht?

Ehrlich gesagt, nicht wirklich. Bei der geringen Zeit, die ich momentan habe

.
(Hast du dir dein Wissen eigentlich selbst beigebracht? )

Zitat:

Wirkliche Klarheit wird dir nur der Debugger liefern können. Einfach mal schauen, was in CData drin steht.
Da CData ToString überschreibt sollte der Inhalt zu sehen sein ohne es aufklappen zu müssen.

Leider ja auch nicht. Hatte ich ja schon versucht. Der SQL-String wird komplett richtig ausgelesen. Auch die Komponente hat den eigentlich den richtigen String bekommen. Nur irgendetwas scheint zu stören und es kommt zum Fehler.

Es handelt sich im Übrigen um diese Komponente:

http://www.datadynamics.com/Products...spx?Product=DC
Allerdings in einer etwas älteren Version (2.5).

**Elvis**

Zitat von Alexander:

Zitat:

Da kennt wohl einer Reflector noch nicht?

Ehrlich gesagt, nicht wirklich. Bei der geringen Zeit, die ich momentan habe

.

Reflector spart Zeit, damit kannst du durch deine und fremde Binaries surfen wie ein einem Browser.

Zitat:

(Hast du dir dein Wissen eigentlich selbst beigebracht? )

Steht ja genug im Internet, und ich habe einen gesunden (kranken?) Spieltrieb.

Zitat:

Leider ja auch nicht. Hatte ich ja schon versucht. Der SQL-String wird komplett richtig ausgelesen. Auch die Komponente hat den eigentlich den richtigen String bekommen. Nur irgendetwas scheint zu stören und es kommt zum Fehler.

Kann es sein, dass Jet zu blöd ist um einen einzelnen line feed (#10) als Zeilenumbruch/Whitespace anzusehen?
Denn bei einem Zeilenumbruch geht definitiv der Cr (#13) flöten, wenn man nicht explizit über einen XmlReader deserialisiert...
Hier mal zur Anschauung

zusammenfalten · markieren

Delphi-Quellcode:

			type

  SampleClass = public class

  public

    property CDataString  : CData;    

  end;

class method ConsoleApp.Main;

  const fileName     = 'data.xml';

  const sampleString = 'SELECT A, B'#13#10

                       'FROM   C';

  method ShowWhiteSpaces(value : String);

  begin

    Console.WriteLine(value.Replace(#32,    '[Space]')

                           .Replace(#9,     '[Tab]')

                           .Replace(#13#10, '[CrLf]')

                           .Replace(#13,    '[Cr]')

                           .Replace(#10,    '[Lf]'));

  end;

begin

  var serializer := new XmlSerializer(typeof(SampleClass));

  if not File.Exists(fileName) then  

    using stream := new FileStream(fileName, FileMode.Create) do

    using writer := new XmlTextWriter(stream, Encoding.UTF8) do

    begin

      serializer.Serialize(writer, new SampleClass(CDataString := sampleString));

    end;

  // mit reader          

  using stream := new FileStream(fileName, FileMode.Open) do

  using reader := new XmlTextReader(stream) do

    with s := serializer.Deserialize(reader) as SampleClass do

      ShowWhiteSpaces(s.CDataString);              

  // ohne reader

  using stream := new FileStream(fileName, FileMode.Open) do

    with s := serializer.Deserialize(stream) as SampleClass do

      ShowWhiteSpaces(s.CDataString);              

  Console.ReadLine();    

end;

Interessant ist was dabei rauskommt:

Output

SELECT[Space]A,[Space]B[CrLf]FROM[Space][Space][Space]C
SELECT[Space]A,[Space]B[Lf]FROM[Space][Space][Space]C

Wie du siehst verhält sich der Overload von DeSerialize, der einen Stream schluckt, nicht wie es ein XmlReader per default macht.

**Alexander**

Das war's auch nicht.
Es sind keine lf's, tabs etc. im String drin. Leider

.

Ich habe gerade mal versucht, das SQL-Statement mit beiden Varianten auszulesen, um den String vergleichen zu können.

markieren

Delphi-Quellcode:

			  TStatement = class

  public

    Connection : TDataBaseConnection;

    [XmlElement('Sql')]

    Sql2 : String;

    Sql : CDataLib.CData;

  end;

Leider bekomme ich da zur Laufzeit einen Fehler:

Zitat:

Projekt dynCubes.exe traf auf die unhandelte Exception-Klasse System.InvalidOperationException mit der Meldung 'Fehler beim Reflektieren des Typs 'dataReader.TControllingData'.'.

Und zwar kommt die Exception so bald der Serializer erzeugt wird:
Ser := XmlSerializer.Create(typeOf(TData)); (TStatement taucht in TData wieder auf).

Ist das nicht möglich oder bin ich da auf dem Holzweg?