Blob als nicht unterstützter Datentyp nur in CGI?

[Jumpy]

Hallo,

die folgende Funktion funktioniert in einer Desktop-Anwendung, aber nicht in der analogen Web-CGI. Dort kommt die Fehlermeldung: "Der Datentyp wird nicht unterstützt".

Beide Anwendungen sind in Delphi 6 und benutzen die selben BL-Logik-Klassen und die selbe Funktion, die ich als den Übeltäter ausgemacht zu haben glaube (wenn ich sie auskommentiere kommt der Fehler nicht).

Hätte jemand von euch eine Idee, woran das liegen könnte?

Delphi-Quellcode:

procedure TBL.StoreFileInDB(const fname:String; var file_id,filesize:integer);
var q:TADOQuery;
    s:TStream;
    f:TFileStream;
begin
  if file_id=0 then
    file_id:=GetNewIDFromSequencer;
  q:=TADOQuery.Create(nil);
  q.Connection:=Con;
  q.SQL.Text:='Select * From '+Table(TabDatei)+' Where ID='+IntToStr(file_id);
  q.Open;
  If FileExists(fname) then
    begin
    if q.RecordCount>0 then
      begin
      q.Edit;
      s:=q.CreateBlobStream(q.FieldByName('Datei'), bmWrite);
      s.Seek(0, soFromBeginning);
      f:=TFileStream.Create(fname, fmOpenRead or fmShareDenyWrite);
      filesize:=s.CopyFrom(f,f.Size);
      end
    else
      begin
      q.Append;
      q.FieldByName('ID').AsInteger:=file_id;
      s:=q.CreateBlobStream(q.FieldByName('Datei'), bmWrite);
      s.Seek(0, soFromBeginning);
      f:=TFileStream.Create(fname, fmOpenRead or fmShareDenyWrite);
      filesize:=s.CopyFrom(f,f.Size);
      end;
    f.Free;
    s.Free;
    q.Post;
    end
  else
    filesize:=0;
  q.Free;
end;

[himitsu]

Irgendeine Unit im CGI nicht eingebunden, aber im Anderen schon?
Die z.B. irgendwas registriert, was im CGI dann nicht vorhanden ist.


Abgesehn davon:
* doppelter Code
* keine Ressourcenschutzblöcke

Delphi-Quellcode:

procedure TBL.StoreFileInDB(const fname:String; var file_id,filesize:integer);
var q:TADOQuery;
    s:TStream;
    f:TFileStream;
begin
  if file_id=0 then
    file_id:=GetNewIDFromSequencer;
  q:=TADOQuery.Create(nil);
  try
    q.Connection:=Con;
    q.SQL.Text:='Select * From &Table Where ID=:FileID';
    q.MakroByName('Table').Value := Table(TabDatei);
    q.ParamByName('FileID').AsInteger := file_id;
    q.Open;
    If FileExists(fname) then
      begin
        if q.IsEmpty then
          begin
            q.Append;
            q.FieldByName('ID').AsInteger:=file_id;
          end
        else
          q.Edit;
        s:=q.CreateBlobStream(q.FieldByName('Datei'), bmWrite);
        try
          s.Seek(0, soFromBeginning);
          f:=TFileStream.Create(fname, fmOpenRead or fmShareDenyWrite);
          try
            filesize:=s.CopyFrom(f,f.Size);
          finally
            f.Free;
          end;
        finally
          s.Free;
        end;
        q.Post;
      end
    else
      filesize:=0;
  finally
    q.Free;
  end;
end;

[Jumpy]

Ich habe weiter getestet und das selbe Problem, bei der Funktion, die Dateien wieder aus der DB holt. Da die einfacher ist, habe ich damit weiter getestet:

Ändere ich das SQL-Statement für die AdoQuery von

q.SQL.Text:='Select * From '+Table(TabDatei)+' Where ID='+IntToStr(file_id); in

q.SQL.Text:='Select ID From '+Table(TabDatei)+' Where ID='+IntToStr(file_id); bekomme ich die Fehlermeldung nicht.

Also ID statt *. wobei die Tabelle eh nur als weiteres Feld das Blob-Feld Datei hat.

Es scheint also irgendwo ein Problem mit einem Blob-Feld in der ADO-Komponente oder bei ODBC zu geben, aber nur im Fall der CGI (die Desktopanwendung habe ich natürlich auf dem selben Server wie die CGI ausprobiert und die geht). Oder hat es etwas mit dem untersch. User-Kontext zu tun unter dem die CGI läuft, da ist ja dann kein User angemeldet?

[Bernhard Geyer]

Du gehst über ADO und ODBC auf eine Oracle-Datenbank.
Da gibt es schon mal drei übeltäter das du nicht mit Blobs arbeiten kannst: Der ADO-Treiber(Die Version), ODBC an sich und der verwendete Oracle-Treiber.
Bist du sicher das alle drei Treiber gleich sind? Könntest du auf einen native direkte Zugriffskomponente (z.b. von DevArt oder FireDac) umstellen?

[Jumpy]

Zitat von Bernhard Geyer:

Du gehst über ADO und ODBC auf eine Oracle-Datenbank.
Da gibt es schon mal drei übeltäter das du nicht mit Blobs arbeiten kannst: Der ADO-Treiber(Die Version), ODBC an sich und der verwendete Oracle-Treiber.
Bist du sicher das alle drei Treiber gleich sind? Könntest du auf einen native direkte Zugriffskomponente (z.b. von DevArt oder FireDac) umstellen?

Ich weiß ja, dass die Zugriffs-Konstellation ungünstig ist, aber in der Desktop-Version klappt es ja. Und ich meine damit, das auch die DB-Zugriffe/Connections in beiden Versionen gleich sind, d.h. wenn es daran läge, warum geht's im normalen Programm, aber nicht in der CGI. Und wie gesagt, ich rede vom gleichen Server/Rechner, wo ich beides getestet habe.

Nichts destotrotz versuch ich jetzt mal zumindest ODBC rauszulassen und direkt via ADO auf Oracle zuzugreifen. Umbaumaßnahme läuft gerade.

[Jumpy]

Problem gelöst. Als ich versucht habe, das bei der Web-Anwendung so umzubauen, dass der Zugriff nicht mehr über ODBC erfolgt habe ich festgestellt, dass dies im Quelltext bereits umgesetzt war mit dem Kommentar, dass der Zugriff ohne ODBC in der CGI-Anwendung viel schneller ist.

Also habe ich das Gegenteil gemacht und die Web-Anwendung auf ODBC zurück umgestellt und siehe da, es klappt der Zugriff auf die BLOB-Felder. Ich werde jetzt in der Web-Anwendung mit zwei Connections arbeiten, einer schnellen ohne ODBC wie bisher und einer mit ODBC für diese zwei Funktionen, die mit BLOB-Feldern arbeiten können müssen. Ist nicht ideal, aber als Workarround funktioniert es. Ich werde das aber besser Kommentieren als es bisher war .

Nur für Interessierte die beiden verwendeten Connection-Strings:

Mit ODBC:
Provider= MSDASQL.1; Persist Security Info=False;User ID=XX;Data Source=DB_ODBC;Password=YY

Ohne:
Provider=MSDAORA.1;Password=YY;User ID=XX;Data Source=DB;Persist Security Info=False

Scheinbar ist bei dem direkten Zugriff der Datentyp-Blob nicht bekannt oder wird nicht erkannt?

[jobo]

MSDAORA für Oracle ist aber ganz alter Stoff oder?
Wir haben den Treiber auch lange Zeit verwendet für ADO / Delphi5, speziell hier gab es nach meiner Erinnerung Probleme mit BLOBS. Aber das und anderes geht seit einigen Jahren mit dem Oracle Treiber viel besser.
Also mein Tipp: Nimm durchgängig Oracle (Instant- oder "Fat" Client), ggF. ohne auch ODBC, lieber OLEDB und alles ist gut.

[Jumpy]

Zitat von jobo:

MSDAORA für Oracle ist aber ganz alter Stoff oder?

Aber sowas von...
Es geht hier um ein ewig altes Programm mit dazugehörigem ewig altem Web-Portal, dass auf einem ewig altem Webserver (Windows2000??) läuft und es gilt das Credo "Nie am running System packen".
Das ist glaub ich mittlerweile alles virtualisiert und von außen auch nicht mehr direkt erreichbar, alles läuft über irgendwelche Umleitungen über Apache-Server und was weiß ich (nicht meine Baustelle).
Ich sollte nur eine "klitzekleine" Ergänzung am Programm vornehemen, kaum Aufwand, sollte doch zum Kundenservice gehören, müsste doch fast umsonst zu machen sein, für so einen langjährigen Kunden,...

[Bernhard Geyer]

Zitat von jobo:

MSDAORA für Oracle ist aber ganz alter Stoff oder?

AFAIK ist war diese Oracle-Treiber von MS eh nur mehr oder minder ein "Proof of Conzept" um zu zeigen das man über ADO auch auf Oracle könnnte.
Es ist eher zufall wenn darüber man eine lauffähige Anwendung erstellen kann.

[p80286]

nunja wenn ich mich richtig erinnere wollte der MS-Treiber nicht so recht mit Memo-Feldern (blobs waren damals noch Zukunftsmusik) und der Oracle-Treiber knirschte bei Fließkommazahlen.

Code:

Provider=OraOLEDB.Oracle.1;

(ado-connection)

Damit geht's ganz ordentlich. Auch blob's.

Gruß
K-H