4. CORBA-TClientDataSet-A Bug ? EOverflow error by using "UNION"

CORBA-TClientDataSet-A Bug ? EOverflow error by using "UNION"

  • A

    Vielleicht kann einer von euch mir helfen.
    Deshlab poste ich hier mal mein newsgroup Beitrag:

    I am establishing a connection to a CORBA server via a TClientDataSet
    component. For reasons of testing I
    connect this component (called CDS_Kombi_All, see screenshot on
    http://www.wegmann.info/Screenshot.jpg) to a DBGrid , because I get
    an EOverflow exception in the linked DataSetAdapter1 of the web application
    during runtime.

    All numeric fields are not properly shown in this DBGrid and in the
    corresponding TAdapter component of the web application,
    alternatively "Overflow" is displayed in these fields during design time.
    Thus the reason for this behaviour is not located
    in the web application.

    The ClientDataSet component accesses a CORBA server, where a TADOQuery is
    located in a data module. When i copy this query
    (called Q_Kombi_All) in my client data module and connect the DBGrid
    component to this query, all data is properly displayed.

    The other queries don't have this Problem.
    So I tried another SQL- Syntax.

    The next SQL- Statement does work:
    -------------------- SQL
    SELECT k.nrdispo,k.nrmandant
    FROM admin.sd_kombi_prod k
    WHERE and k.nrdispo=426283

    -------------------- SQL
    The field "nrmandant" (an Integer) is shown right.

    This SQL- Statement dosen't work how I want. The ClientDataSet can't work
    with it:

    -------------------- SQL
    SELECT k.nrdispo,k.nrmandant
    FROM admin.sd_kombi_prod k
    WHERE and k.nrdispo=426283
    union all
    SELECT k.nrdispo,k.nrmandant
    FROM admin.sd_kombi_prod k
    WHERE and k.nrdispo=426283
    -------------------- SQL

    now the field "nrmandant" is shown as an defaultvalue "Ueberlauf" for the
    overflow- Error.

    Is it a bug ? I Think its a Bug in the TClientDataSet. I tried the SQL-
    Statement in a TADOQuery without problems.
    At least, using "UNION" for "UNION ALL" doesn't help too.

    I use:
    WIN 2000 Professional
    BCB6 Enterprise mit Servicepack4.
    How can I fix my Problems ?
    Oracle 9.2 as Database

    Thanks for any help.

    Andreas

    0
  • B

    - sorry, i am not speak english very well, because we are living in "germany", so i can not understand this text -

    0
  • A

    Dann auf Deutsch:

    Ich hab ein CORBA- Server erstellt und in ein exerne Datenmodul ein DataSet über DataSetProvider veröffentlicht.

    In ein Client- Programm greife ich über DCOM und TClientDataSet auf diesen Provider zu.

    Wenn die SQL- Anweisung in der Query des DataSets eine "UNION" oder "UNION ALL" enthält bekomme ich in der Clientanwendung besagten Fehler.
    Was ja eigentlich nicht sein kann. Ich habs lokal im Client mit DOQuery- Komponenten probiert, wo natürlich die "UNION"- Anweisungen funktionieren.

    Der Fehler liegt meiner Meinung nach in der TClientDataSet- Komponete.

    Kann dieses jemand Bestätigen oder Lösungsvorschläge anbieten ?

    0
  • A

    och kommt, kann ja nicht sein, dass niemand der Fehler aufgefallen ist.

    Angeblich gibt es ein Patch dazu. ICh kann aber dergleichen nicht finden. Ich hab das Update."cb6_upd4_ent.exe" von Borland gezogen und installiert.

    Kein Bugfix 😞

    Weiss jemand noch Patches für den BCB6, die irgendwo im Borlanddurcheinander versteckt schlummert ?

    I despaired 😞

    0
  • P

    Hi Andreas 😉
    kann Dir zwar bei Deinem eigentlichen Problem nicht weiterhelfen, hatte noch nix mit CORBA zu tun und für unsere Oracel DB verwende ich eine eigent Kompo, was mir aber auffiel, was macht das "and" direkt hinter dem "where" in deinem Query 🙄

    Nachtrag:
    Was mir noch gerade einfällt, vor einieger Zeit hatte mein Chef auch ein merkwürdiges Verhalten mit Overflow oder so ähnlich (Delphi). Umgehen konnte wir das Ganze indem wir das Feld mit "to_char" in einen anderen Datentyp umwandelten, wie gesagt verwenden wir Oracle.

    0
  • A

    Hi Peter,

    Peter schrieb:

    was macht das "and" direkt hinter dem "where" in deinem Query

    och, ich hab die Query gestaucht. Die war ursprünglich 12 DINA4 Seiten lang. Wollt ich den Lesern nicht zumuten. Beim Kürzen ist mir da wohl ein Fehler unterlaufen. Spielt aber beimn Problem keine Rolle.

    Wir verwenden auch Oracle.
    Genauer:Oracle9.2

    Was mir noch gerade einfällt, vor einieger Zeit hatte mein Chef auch ein merkwürdiges Verhalten mit Overflow oder so ähnlich (Delphi). Umgehen konnte wir das Ganze indem wir das Feld mit "to_char" in einen anderen Datentyp umwandelten, wie gesagt verwenden wir Oracle.

    Das ist genau daß, was ich hier habe. Sicherlich könnte ich auch mit to_char arbeiten. Allerdings ist es ja nicht Sinn der Übung alle numerischen Datentypen nach Char zu umwandeln zu müssen. Mal abgesehen von der Performance. Die Query rattert mit 5 ineinander geschachtelten Unterabfragen über riesige Tabellen (je ca 3-10 Mio. Datensätze). Im Select- Part sind noch SubSelects, die Daten über weitere SubQueries berechnen. Da alles nach char zu konvertieren würde wohl die Query tief in den Keller ziehen.
    Davon mal abgesehen würde ich Tage brauchen um die Datensicherheit danach wieder herzustellen.

    Hatte euer Chef irgendwo Support gekommen ?
    Wie lange ist das her als das Problem auftrat. In einer Früheren Version als 6 ? ( Ob Delphi oder BCB spielt ja keine Rolle)
    Hat euer Chef auch TClietDataSet verwendet oder treten diese Schwierigkeiten auch bei anderen Kompontenten auf ?

    Hatte euer Chef irgendwo Support gekommen ?
    Wie lange ist das her als das Problem auftrat. In einer Früheren Version als 6 ? ( Ob Delphi oder BCB spiel ja keine Rolle)
    Hat euer Chef auch TClietDataSet verwendet oder treten diese Schwierigkeiten auch bei anderen Kompontenten auf ?

    und natürlich:

    und für unsere Oracel DB verwende

    das interessiert mich. Hast du eine TClientDataSet- Kompontente neu geschrieben ?

    *lechzend_nach_info_kratzend*

    0
  • P

    Was mein Chef damals noch gemacht hat kann ich leider nicht sagen. Ich hatte selber ein sehr komlexes Projekt am Hals und habe das Problem nicht mehr mitverfolgt. Er hat es dann irgendwie anderst gelöst. Die 'to_char' Umwandlung hatte zwar funktioniert, aber er mußte sein Programm für ein paar Datenbanken anpassen, Oracle, Sybase und MySQL waren es glaube ich. Da es 'to_char' nur bei Oracle gibt hat er wohl irgend ne andere Lösung gefunden. Ich hab aber jetzt Urlaub und kann ihn nicht fragen 😞
    Da gerade Inserts über BDE suamässig langsam waren (Import Programm), hab ich mir vor Jahren eine eigene DB-Klasse geschrieben welche direkt auf OCI aufsetzt. Da ich darin zu OCI hin generell nur mit Strings arbeite ist es vollkommen egal, was für Datentypen von Oracle geliefert werden. Entsprechende Properties sorgen dann für eine entsprechende Umwandlung nach int oder double. Das funktioniert sehr gut, ist um Klassen schneller als per BDE bzw. ODBC und brachte noch nie Probleme mit sich. Ok, bei Threads hats mal geklemmt, aber das hab ich dann auch recht einfach in den Griff bekommen 😉 Die Klasse ist natürlich mit der Zeit auch gewachsen aber sie hat sich sehr bewährt, ich will eigentlich mit nichts anderem mehr arbeiten. Wenn es irgendwann mal ne Besonderheit gibt bau ich halt ne entsprechende Funktion dazu 😉

    0
  • A

    hm,

    kannst du dein Chef mal Fragen wenn du dich aus deinen Urlaub wieder ins Büro schleifst?

    Da es 'to_char' nur bei Oracle gibt hat er wohl irgend ne andere Lösung gefunden

    das würde mich brennend interessieren.

    hab ich mir vor Jahren eine eigene DB-Klasse geschrieben welche direkt auf OCI aufsetzt

    interessant!
    Oracle C++ Call Interface wenn ich mich nicht irre.

    Ich hab so was auch schon mal angedacht. Zumal selbst die ADO- Komponenten, welche wohl zu den besseren bei der VCL gehören, eine Fehlentwicklung sind:
    1. Parameter
    - Parameter die nicht in SQL mehrfach benutzt werden können (wie uncool)
    - Starre Parameter die nicht einmal richtig funktionieren ( siehe String und Datumstyp- Kombinationen)
    - mal abgesehen von Parameter bei Queries, die sich nicht einmal ineinander verschachteln lassen.

    2. StoredProc
    Die StoredProc- Komponenten sind ein klassischer Fall. Die Dinger taugen nicht einmal zum Boden wischen.
    Ein simplen Aufruf bekommt man ja noch hin. Aber wenn’s ein wenig komplizierter wird hört’s auch schon auf:

    - Datentypen die stets mit sich selbst nicht vereinbar sind. (die Bugs haben die immer noch nicht im Griff)
    - Type-Mapping -> Fehlanzeige
    (oh, ich schweif vom Thema ab....)

    naja, so kann ich stundenlang weitermachen....

    Ich hab mir dann QueryBuilder- Komponeten gebaut, die die mangelnde Flexibilität der VCL- Komponenten kompensieren sollen. Funktionieren recht gut. Die Kommunikation mit dem Server läuft aber immer noch über ADO- Komponenten und OLE- Provider. (schon komisch, so schafft sich jeder seine eigene kleine Welt )

    Ich habe mich bisher vor den Arbeitsaufwand gescheut, der in der Entwicklung von OCCI- Komponenten steckt.
    Wie würdest du den Aufwand beurteilen. Wie ist das Aufwand/Vorteil/Nutzen- Verhältnis ?

    Wie hast du die Anbindung an VCL- Komponenten realisiert?
    Verwendest du den BCB oder eine andere Umgebung ?
    Ist OCCI schnelle als über OLE- Provider oder tut sich da nichts ?
    Wie hast du die Anbindung an externe Datenmodule und die Kommunikation über Applicationserver gelöst ?
    Wie könnte ich am einfachsten einen Einstieg bekommen ?
    Fragen über Fragen 🙂

    *vor_Neugier_platzend*

    0
  • P

    Na klar kann ich meinen Chef mal fragen, aber das dauert noch 2 Wochen, denn solange hab ich noch Urlaub. Hoffentlich vergess ichs dann nicht 🙄 Kannst mich ja dann mit ner EMail erinnern 😉
    Mit OLE hatte ich bisher noch überhaupt nichts zu tun und einen Applicationserver haben wir nicht. Rein technisch gesehen lade ich in der Klasse einfach die OCI.DLL und kapsle die ganzen Funktionen. Um das Ganze mit Delphi kompatibel zu machen bastelte ich am Anfang erst ne DLL die die OCI-Calls etwas einfacher bedienbar machte und baute dann quasi um die DLL herum eine Pascal Klasse damit mein Chef das Teil auch verwenden konnte. Ich selber verwende nur den BCB und bin deshalb kein Pascal Crack. Den Umweg über noch eine DLL wählte ich deshalb, da ich Pascal und API Aufrufe recht furchtbar finde und mit C wesentlich besser zurecht komme. Naja, das DLL Gedönse ging mir aber recht schnell auf den Wecker, vor allem bei CGI-Progs wollte ich nicht so viel Ballast mitschleppen müssen, so daß ich daraus ne eigenständige C++ Klasse bastelte und diese auch nach wie vor verwende. Der Code sieht zwar inzwischen teilweise etwas überarbeitungsbedürftig aus vor allem weil nach und nach was hinzugekommen ist teils aus Fehlern, teils aus neuen Erkenntnissen, aber was solls, es funktioniert und zum Überarbeiten fehlt die Zeit. Deswegen kann ich Dir auch nicht den benötigten Zeitaufwand für das Teil nennen. Am Anfang wars etwas ne Durststrecke bis ich das Oracle Caller Interface verstanden hatte, aber dann gings ganz gut. Alle Möglichkeiten des OCI hab ich noch gar nicht ausgeschöpft, aber das brauchts momentan auch nicht.
    Wie gesagt behandle ich alle Werte wie Strings. Beim Aufbau z.B. eines 'selects' ja sowieso und die Ergebnissdaten von Oracle werden zunächst in Stringlisten geschrieben und können dann per Property ausgelesen werden. So sieht dann ungefähr ein SQL Gedöns aus:

    TCOCI Oracle(USER, PASSWORD); // Geht auch ohne Parameter mit separatem Login

Oracle.AutoMessage=false;  // sonst generiert Oracle selber eine Fehlermeldung
if(Oracle.IsNotReady)
{   ShowMessage(Oracle.Status);
    return;
}

Oracle.SQLClear();
Oracle.SQLAdd("select");
Oracle.SQLAdd("  FELD1, FELD2");
Oracle.SQLAdd("from");
Oracle.SQLAdd("  TABELLE");

if(!Oracle.ExecSQL())
{   ShowMessage(Oracle.Status);
    return;
}

while(Oracle.GetRow())
{   ListBox.Items.Add(Oracle.Field[0]);  // Liest Feld1 aus
    ListBox.Items.Add(Oracle.Field[1]);  // Liest Feld2 aus
    ListBox1.Items.Add(Oracle.FieldByName["FELD1"]);  // Liest Feld1 aus
    ListBox1.Items.Add(Oracle.FieldByName["FELD2"]);  // Liest Feld1 aus
}

// usw.

    Der Code soll nur als Beispiel dienen, hab ich "freihändig" runtergetippt 😉
    Es gibt auch noch einen Konstruktor dem man die LDA der ersten Instanz übergeben kann. So kann man beliebig viele Instanzen auf einen einzigen Login erstellen ...
    Der Aufruf einer StoredProcedure funktioniert auf dem selben Weg wobei ich in der Regel PL/SQL Skripte per Programm generiere und dann zu Oracle schiebe und nicht als StoredProcedure auslege. In meinem letzten Projekt, welches noch nicht ganz abgeschlossen ist, verwende ich sehr viel PL/SQL und union/union all Verknüpfungen. Größere Probleme hatte ich damit nicht, mal abgesehen davon, daß ich das ein oder andere Mal Bockmist geschossen hatte, aber das lag dann wohl mehr am Programmierer :D. Nur ein Mal funktionierte ein PL/SQL Prog nicht wie erwaretet, nach Analyse stellte ich fest, eine Variable wurde einfach nicht zugewiesen obwohl da eindeutig z.B. x:=0; geschrieben stand. Die Var hatte hinterher immer den Wert NULL und nicht 0. Diese Problem schreibe ich aber eher Oracle (9.?) zu als meiner Klasse bzw. OCI.
    Hups, jetzt hab ich doch etwas viel gelabert, deswegen erst mal Schluss 😉

    0
  • A

    Hi,

    Hoffentlich vergess ichs dann nicht Kannst mich ja dann mit ner EMail erinnern

    Klar mach ich das. Hab mir gleich ein Erinnerungstermin am 23ten gesetzt. 😉
    Den 22sten verschone ich dich also noch 😃

    danke erstmal für deine Unterstützung und deine ausführliche Beschreibung .
    Dein Beispiel sieht gut aus. Ich glaub ich muss mich mal damit beschäftigen. Ich hab jetzt mal in der Oracle- Doko geblättert und auch einiges gefunden. Ich werde wohl nächtste Woche anfangen zu lesen 🙂

    Ich glaub schwierig wird es, wenn man dazu eine Applicationserver- Schnittstelle schaffen will. Ich möchte ja nicht direkt von den Clients oder den Webanwendungen auf Oracle rumhampeln. Die Anwendungen sollen eine gemeinsame Geschäftslogik auf einen Corba oder SOAP- Server nutzen und zu Thin- Clients und Webanwendungen werden. Das Geilste wäre, wenn man ein DatenProvider, ähnlich dem TDataSetProvider, mit der OCI- Schnittstelle realisieren könnte. Dann könnte ich ohne großes IDL- Gehampel mit Corba arbeiten. Oder man muss halt eine andere Komunikationsebene nehmen oder eine Neue aufsetzen, was ein wenig mehr Arbeit bedeuten würde.

    *GrübelGrübel*

    Vielen Dank für deine Inspiration. Hilft mir bestimmt noch weiter. Wenn auch nicht direkt bei diesen Problem kann ich Das mit Sicherheit noch gebrauchen.

    0
  • P

    Na dann viel Erfolg. Das Thema SOAP/XML wird wohl in nächster Zeit auch auf mich zukommen, Application Server warscheinlich weniger. Wir connecten direkt zur DB, das reicht momentan. So viele DB-User habe wir nicht 😉

    0
Anmelden zum Antworten