ADOQuery in DLL spinnt

[gsh]

Hi DPler

Ich hab ein großes Problem. Ich ein Programm geschrieben das auf die Datenbank zugegriffen hat. Alles wunderbar. Bis ich mich entschied alles in eine DLL zu packen. Naja jetzt ist alles in der DLL und er bringt nur noch Fehler. Ich habe ja nichts vom Code geändert ist jetzt alles was die Datenbank angeht in die DLL gepackt. Jetzt kommt der Witz dabei der Fehler tritt auf nachdem er die procedure SQLBefehl 8-10 durch hat. Es ändert sich der SQL befehl nicht einmal. Und wo des ganze im Programm war hat alles wunderbar funktioniert :wall:

Delphi-Quellcode:

procedure SQLBefehl(SQL : String); stdcall;
begin
  ADOQuery.Active := false;
  ADOQuery.SQL.Clear;
  ADOQuery.SQL.Add(SQL);       <--- Hier kommt der Fehler. Im Anhang
  ADOQuery.Active := true;
end;

function QueryData(FeldName : String) : Variant; stdcall;
begin
  result := ADOQuery[FeldName];
end;

exports SQLBefehl, QueryData;

begin
  ADOQuery := TADOQuery.Create(nil);
  ADOConnection := TADOConnection.Create(nil);
  ADOQuery.Connection := ADOConnection;
  ADOConnection.ConnectionString := cADOConnectionString;
  ADOConnection.Mode := cmShareExclusive;
  ADOConnection.Provider := 'MSDASQL.1';
end.

[Elvis]

Mache aus der DLL ein Package und du kannst sogar Strings nehmen. Außerdem wird die VCL bei einer Delphi EXE + Delphi DLL zweimal geladen. Packages sind Delphis ClassLibs, DLLs sollten IMHO nur benutzt werden wenn man auch mit anderen Sprachen auskommen will.

[gsh]

ich will aus verschiedenen Gründen eine DLL benutzen
also mein prob. warum funkt des nicht

[Brüggendiek]

Hallo!

Hast Du daran gedacht, die Unit ShareMem als erste Unit aufzunehmen?
Das ist bei String-Parametern in einer DLL nötig (jedenfalls bei früheren Delphi-Versionen). Beim Erzeugen einer neuen Unit sollte das auch da drin stehen.

Alternative: PChar oder ShortString verwenden.

Gruß

Dietmar Brüggendiek

[gsh]

ja aber warum kann des der fehler sein?
wenn ich debuge wird der string ja wunderbar übergeben :wall:

Ich ich werds mal mit PChar probieren


//edit: Danke :thumb:
Jetzt funktionierts :-D, ich verstehs trotzdem nicht warum :stupid: (kann mir jemand des erklären? würd mich interessieren)

[MikeZ]

Du musst das COM-Subsystem mit CoInitialize(nil); vor dem Verwenden von COM-Objecten in DLLs initialisieren, und beim Entladen der DLL wieder mit CoUnInitialize; aufräumen. Bei multithreaded Anwendungen sollte in jedem Thread ein CoInitialize/CoUnInitialize Paar in der Execute-Methode stehen.

use ActiveX (bzw. OLE2 in älteren Delphi-Versionen)


ShareMem wird eigentlich nur benötigt, wenn man in extern deklarierten Funktionen Delphi-Strings verwenden will.

[gsh]

und für was braucht man des CoInitialize bzw. CoUnInitialize? :wiejetzt:

[gsh]

:wall:

Ich hab des jetzt alles wunderbar zum laufen gebracht auch ohne CoInitialize(nil);
Naja und plötzlich (ohne des ich beim laden der DLL oder bei der DLL selbst etwas verändert hab) kann er diesen Befehl nicht mehr ausführen:

Delphi-Quellcode:

ADOQuery := TADOQuery.Create(nil);

Fehler: im Anhang

Das einzige was ich beim Prog. verändert hab war das ich eine TWebBrowser kompo gelöscht habe (hat nichts mir der Datenbank zu tun). Auch wenn ich sie wieder hinzufüg dann gehts nicht mehr :wall:

[gsh]

*push*

[gsh]

*push²*

[Bernhard Geyer]

Wie wäre es wenn Du mike2's Tipp mit CoInitialize(nil) wieder einbauen würdest?

[gsh]

hab ich natürlich gleich nach dem Fehler ausprobiert (bevor ich gepostet hab) => ohne erfolg

[Bernhard Geyer]

Ist ADOQuery überhaupt schon angelegt?
Deine erste Fehlermeldung deutet darauf hin das du irgendwo mit einem nil-Zeiger/referenz arbeitest.

[gsh]

das anlegen ist ja genau des prob.

wenn ich

Delphi-Quellcode:

ADOQuery := TADOQuery.Create(nil);

aufrufe dann tritt der fehler auf.
Des hat ja schon alles wunderbar funktioniert aber auf einmal ...

[generic]

der twebbrowser hat coinit aufgerufen.

du musst das tun. sonst laeuft das com nicht.
das ado unter delphi hat ein multithreadingproblem wenn du die selbe connection nutzt.
probier mal das sharemem aufzurufen und/oder das tadobla.create in einen mutex/criticalsection zu packen

[hardy1234]

hast du dran gedacht, den speicher bei den funktionen und prozeduren wieder freizugeben? wenn du das nicht machst fallen die reihenweise aufer schnauze, vo speicherverbrauch mal ganz abgesehen. die gilt insbesondere für die rückgabewerte von funktionen. die methode entspricht dem malloc aus c++ und ist bei dll's immer angeraten.

etwa so:

func blabla(paramlist): output;
var
par: ^output;
begin
new(par);
// hier dein code
^par:= result;
Result:= ^par;
free(par);
end;

bei dem interbase-paket ist ein entsprechendes bsp zu finden.

[gsh]

@generic:

Delphi-Quellcode:

CoInitialize(nil);
  ADOQuery := TADOQuery.Create(nil);

hab ich ja schon probiert

sharmem benutzt ich nicht
mutex? criticalsection?

@hardy1234: Ahm was hat des mit meinem prob. zu tun? :wiejetzt:

[gsh]

:wall: ich versteh die welt nicht mehr
plötzlich geht das erstellen von der ADOQuery

Nur geht der Befehl:

Delphi-Quellcode:

ADOConnection.Open;

nicht mehr. *grml*
Aber des nur auf meinen Laptop, bei meinem normallen PC gehts. Der ODBC Treiber ist aber installiert und es hat ja schon funktioniert.

Könnt ihr mir bitte helfen?

[gsh]

*push*

[Bernhard Geyer]

Zitat:

Zitat von gsh

Aber des nur auf meinen Laptop, bei meinem normallen PC gehts. Der ODBC Treiber ist aber installiert und es hat ja schon funktioniert.

Was willst Du mit ODBC beim Zugriff auf Access? Für Access kannst Du doch direkt mit dem Jet-Treiber zugreifen.

Ich glaube es wäre mal an der Zeit eine kleine Testanwendung zu schreiben. Ich weiß absolut nicht mehr was du aktuelle an den Tipps eingebaut hast bzw. was Du geändert hast. Sonst reden wir aneinander vorbei.

[gsh]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von gsh

Aber des nur auf meinen Laptop, bei meinem normallen PC gehts. Der ODBC Treiber ist aber installiert und es hat ja schon funktioniert.

Was willst Du mit ODBC beim Zugriff auf Access? Für Access kannst Du doch direkt mit dem Jet-Treiber zugreifen.

Ich will mal daweil ich den Access Treiber die Datenbank benutzen.

Zitat:

Zitat von Bernhard Geyer

Ich glaube es wäre mal an der Zeit eine kleine Testanwendung zu schreiben. Ich weiß absolut nicht mehr was du aktuelle an den Tipps eingebaut hast bzw. was Du geändert hast. Sonst reden wir aneinander vorbei.

Hab ich gerade gemacht und nun kommt auch eine andere Fehlermeldung (frag mich jetzt nicht warum). Siehe Anhang. Aber die kommt nur bei meinem Laptop (und ja ich hab des Office Packet auf meinem Laptop drauf)

[Bernhard Geyer]

Zitat:

Zitat von gsh

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von gsh

Aber des nur auf meinen Laptop, bei meinem normallen PC gehts. Der ODBC Treiber ist aber installiert und es hat ja schon funktioniert.

Was willst Du mit ODBC beim Zugriff auf Access? Für Access kannst Du doch direkt mit dem Jet-Treiber zugreifen.

Ich will mal daweil ich den Access Treiber die Datenbank benutzen.

Ja, aber nicht den ODBC-Jet-Treiber sondern direkt den ADO-Provider "Microsoft JET 4.0 OLE DB Provider" statt des ODBC-Providers.

[gsh]

aha des sagt mir jetzt gar nichts kannst du mir des bitte genauer erklären.
bzw. code beispiele

[gsh]

*push*