XSQLDA Indexfehler ....

[Billa]

Hallo zusammen!

ich hatte vor einiger Zeit ein kleines Problem: Ein Programm (D6 Enterprise unter XP kompiliert) greift auf eine Datenbank (mittlerweile FB 2.0) via Stored Procedures mit mehreren Parametern zu. Kurz vor Umstellung des Entwicklungssystems auf D7 - ist schon eine Weile her - kam ein neuer Parameter (BLOB) dazu. Die SPs wurde neu initialisiert und alles war gut. Nun sollte derselbe Quelltext mit D7 unter Windows 7 noch einmal kompiliert werden. Alles schien in Ordnung, bis auf den Aufruf dieser SP. Dort gab es plötzlich die Fehlermeldung "XSQLDA Indexfehler...". Abhilfe hat erst einmal geschaffen, den Zugriff von SP auf ein SQL-Statement umzustellen. Das funktionierte sofort wie erwartet. Wenn man die Variante mit der SP versucht, knallt es zuverlässig beim Aufruf. Spasseshalber haben wir das Ganze auch mal unter Vista mit D7 kompiliert und siehe da: derselbe Fehler. Unter XP mit D7 ist alles noch ok.

Nun greifen statt wie bisher 3 künftig ca 40 Clients auf die Datenbank zu, deshalb sollte aus Performancegründen Einiges in SPs ausgelagert werden. Dabei fiel mir das alte Problem wieder ein. Wie gesagt: ich habe damals einen Workaround gefunden, bin aber trotzdem neugierig, woran das wohl liegen kann? Vielleicht hat jemand einen Tipp?

Ach ja: es werden ausschließlich Standardkomponenten verwendet!

[hoika]

Hallo,

definiere "Standard-Komponenten".
Sollte es IBX sein, dann hoffentlich eine "aktuelle".
Jede Delphi-Version hat ja eine andere Version mit drin.

Andere Ursache könnte die verwendete Client-Bibliohek sein.
Wenn Server und Client nicht die gleiche Version haben,
kann es Probleme geben.

XSQLDA Indexfehler

Die genaue Fehlernummer wäre noch interessant.

Hier noch ein interessanter Link
1



Heiko

[Billa]

Es sind die "Interbase"-Komponenten aus der IDE ... Fehlernummer habe ich leider im Augenblick nicht. Die Zuweisung an die Parameter erfolgte "ByName". Firebird-Client und Server sind jeweils derselbe Stand (zuerst 2.0.5, mittlerweile Firebird-2.1.3.18185). Es existiert auf den Clients nur eine Version der fbclient.dll (in zwei Verzeichnissen). Datenbankdialekt ist 3

Wie gesagt: es brennt nicht, weil der Workaround ja funktioniert. Habe im Web auch schon einige Anregungen gefunden, man möge die SPs im Datenbankserver neu definieren. Hat aber gar nix gebracht. Ich glaube andererseits auch nicht wirklich, dass es was mit dem Betriebssystem zu tun hat... es sieht halt nur so aus :(

@Tipp 1: Der "böse" Parameter ist zwar auch ein BLOB, funktioniert in der Query mit ParamByName aber einwandfrei ... lediglich bei der Verwendung von SP knallt es.

[hoika]

Hallo,

ohne die SP zu sehen, ist unmöglich es, was zu sagen.
Wie sehen denn die Parameter aus ?

Was meint SP neu aufbauen gemeint ist, ist folgendes.

Nutzt die SP andere SP's, müssen die Parameter (anzahl, Reihenfolge) immer stimmen.

Wird z.B. eine SP nachträglich geändert, kann es passieren,
dass eine andere SP sie immer noch mit "alten" Parametern aufruft.

Was heisst eigentlich Blob als Parameter ?



Heiko

[Billa]

Tja, die SP ist völlig "stand alone", d.h. sie wird (bisher) von keiner anderen SP aufgerufen.
Hier der Text:

SQL-Code:

create procedure LEISTUNG_INS (
    LEISTUNG_ID integer,
    LEISTUNG_ART integer,
    LEISTUNG_NAME1 varchar(50),
    LEISTUNG_NAME2 varchar(50),
    LEISTUNG_EK double precision,
    LEISTUNG_AUFSCHLAG double precision,
    LEISTUNG_ZUSCHLAG double precision,
    LEISTUNG_IDLIEFERANT integer,
    LEISTUNG_IDSTEUER integer,
    LEISTUNG_TEXT blob sub_type 0 segment size 80)
as
BEGIN
  INSERT INTO LEISTUNG (
    LEISTUNG_ID,
    LEISTUNG_ART,
    LEISTUNG_NAME1,
    LEISTUNG_NAME2,
    LEISTUNG_EK,
    LEISTUNG_AUFSCHLAG,
    LEISTUNG_ZUSCHLAG,
    LEISTUNG_IDLIEFERANT,
    LEISTUNG_IDSTEUER,
    LEISTUNG_TEXT)
  VALUES (
    :LEISTUNG_ID,
    :LEISTUNG_ART,
    :LEISTUNG_NAME1,
    :LEISTUNG_NAME2,
    :LEISTUNG_EK,
    :LEISTUNG_AUFSCHLAG,
    :LEISTUNG_ZUSCHLAG,
    :LEISTUNG_IDLIEFERANT,
    :LEISTUNG_IDSTEUER,
    :LEISTUNG_TEXT);
END

Schlichter geht es kaum.


PS.: Es gibt andere SPs in der Datenbank, die prinzipiell genauso aufgebaut sind und keine Fehler generieren..

[hoika]

Hallo,

wie übergibst du den Blob im SP-Aufruf ?
Ich gebe zu, Blobs abe ich bisher immer per Query geschrieben.


Heiko

[Billa]

An mehreren Stellen bei verschiedenenen Tabellen immer nach dem Muster:

Delphi-Quellcode:

ParamByName('TABELLE_FELDNAME').asString := GetRTFString( edText )

edText ist ein TRichEdit

Delphi-Quellcode:

function GetRTFString(ARichEdit: TRichEdit): string;
var
  AStream: TMemoryStream;
begin
  Result := '';
  AStream := TMemoryStream.Create;
  try
    ARichEdit.Lines.SaveToStream(AStream);
    AStream.Position := 0;
    if AStream.Size > 0 then
    begin
      SetLength(Result, AStream.Size);
      AStream.ReadBuffer(Result[1], AStream.Size);
    end;
  finally
    AStream.Free;
  end;
end;

Klappt nur für Bilder nicht. Aber das liegt am TRichedit und wird auch nicht gebraucht

[hoika]

Hallo,

Zitat:

PS.: Es gibt andere SPs in der Datenbank, die prinzipiell genauso aufgebaut sind und keine Fehler generieren..

Prinzipiell, OK. Aber es gibt schon Unterschiede, oder ?


Was mir auffällt.
Du übergibst den Parameter mit AsString, nicht AsBlob.

TBlobData ist ein String, OK.
Aber

Aus der Hilfe.

Zitat:

AsBlob setzt die Eigenschaft DataType auf ftBlob.

Heiko

[Billa]

Klar gibt es Unterschiede: andere SPs mit anderen Parameter- bzw. Feldnamen, weil eben andere Tabellen ... aber sonst keine Unterschiede. Vor allem keine (XSQLDA-Index-) Fehler.

@AsBlob: Ich benutze das z.B. bei Bilddateien u.ä. Speziell bei Texten (Richedit, HTML) etc. ist der Umweg über "String" sehr nützlich, wenn mal vor der Übergabe geparst oder noch etwas eingefügt/ersetzt werden soll...

[hoika]

Hallo,

mag ja sein.
Aber du übergibst einen String und die SP
erwartet einen Blob (genauer eine Blob-Id).

Mit "andere SP's" meinte ich, ob du dort auch Blobs
als Parameter hast.

Probier doch einfach mal AsBlob aus.


Heiko