Das Array übergibt alle Datensätze an den Oxid-Shop, bzw. alle zu ändernden Daten, in diesem Beispiel die Artikel. Gibt's aber auch für User, Attribute, Kategorien, Gruppen etc... Zu diesem Behufe wird das Array (bei größeren Mengen segmentiert) gefüllt und dann mittels
SOAP-Schnittstelle an die Gegenstelle im Oxid übergeben. Das war sowieso schon eine Turbogeniale Kagge, das alles zum laufen zu bringen. Zuerst hab ich's in meinem D7 programmiert bis wir draufgekommen sind dass die
SOAP-Umsetzung in D7 echt krank ist (alle Umlaute haben die Felder terminiert, z.B.). Danach hab ich das ganze nochmals im D2010 von einem Bekannten/Kunden gebastelt, da waren dann die nilables unser Thema... Weil wenn ich nur 2 Felder (OX-ID und Titel) raufgespielt habe war im Oxid der restliche Satz leer (also alle numerischen Werte auf 0, alle booleans auf False, alle Strings "")... Echt geil.
Prinzipiell frag ich mit Delphi per
WSDL-Importer die
SOAP-Schnittstelle ab und bekomme exakt diese Aufrufsbeschreibung, eben mit Array. Und mit der TObjectList muss ich mich noch beschäftigen... Ich werds mal googlen.
Mein Destruktor ruft für jedes einzelne TXS-Objekt (egal ob TXSBoolean, TXSString, TXSInteger oder TXSDecimal) ein
Code:
SysUtils.FreeAndNil(FELDNAME);
auf, beim Artikel eben über 113 Felder, d.h. wenn ich einen Artikel destroye macht er automatisch alle (verwendeten) Felder platt. Das hab ich mittlerweile ausprobiert und tut auch...
Was ich noch nicht gefunden habe sind ominöse Speicherleaks hinsichtlich
Unicode Strings??? Die Medlung sagt UnicodeString x 2 und nächste Zeile UnicodeString x 1. Aber das ist eine andere Baustelle und noch nicht vordringlich.
Hab heute hier wieder mal extrem viel gelernt und bedanke mich herzlichst bei allen Beteiligten!!! DANKE!!!
greetz, Erwin J.