Announcement

**Andreas Kosch** · 01.03.2000, 09:07

Hallo,

ich gehe einmal davon aus, das Delphi 5 verwendet wird und der eigene COM-Server als Komponente im Formular plaziert wurde. F�r das Server-Ereignis wurde dann im Objektinspektor eine Ereignisbehandlungsmethode angelegt. Wie sieht die Implementierung in dieser Methode aus? Werden separate Threads verwendet? Werden �ber SendMessage Botschaften verschickt? Wird ein modaler Dialog oder eine MessageBox etc. aufgerufen?

Falls ja, muss die Anwendung ge�ndert werden. Wird ein modaler Dialog in einem ung�nstigen Moment aufgerufen (d.h. bei einem aktiven Sink-Objekt-Aufruf), bleibt der Server-Thread, der gerade im Callback-Aufruf ist, solange h�ngen, bis der Dialog wieder geschlossen wird.
Um dieses Problem zu umgehen, mu� das Sink-Objekt v�llig vom prim�ren Thread (STA0) der Anwendung getrennt werden, indem auch das Sink-Objekt in einem eigenem Thread (und damit in einem eigenem STA) ausgef�hrt wird.

P.S. Was passiert, wenn alle Critical Section-Aufrufe auskommentiert werden?
&#10

**B. Petenyi** · 01.03.2000, 14:10

Erstens danke f�r die Antwort!

Es handelt sich um DTS Automatisierung von SQL Server 7.0. Die Package wird richtig gestartet, am Anfang beim OnStart kann ich noch sogar ein ShowMessage anzeigen. Beim OnProgress kann ich nicths mehr machen, das Programm bleibt nicht nur bei ShowMessage stehen, sondern auch bei Memo.Lines.Add, ProgressBar usw. Wenn ich eben die VCL benutzen will. Aus dem Grund habe ich das CriticalSection eingebunden, hilft leider nichts. Wenn ich alles auskommentiere (Memo.Lines.Add,ProgressBar) funktioniert alles richtig. Es ist bestimmt ein Thread-Problem.

Dank

**Andreas Kosch** · 02.03.2000, 09:27

Hallo,

wie sieht ein Minimal-Beispiel aus, mit dem das Problem reproduziert werden kann

06.03.2000, 23:06

Hallo,

ich habe inzwischen eine halbe L�sung gefunden, die mir �berhaupt nicht gef�llt. Man kann bei dem DTS-Package einstellen, dass die Steps in der Mainthread ausgef�hrt werden sollen. Diese Variante ist aber wirklich nur eine VB L�sung.
Die DTS-Package von Microsoft ist free-threaded
Kurz die DTS.TLB
IDTSStdObject = interface(IDispatch)
_Package = interface(IDTSStdObject)
Delphi Wrapper
TPackage = class(TOleServer)


Wie k�nnte ich dieses Package als Multiinstance implementieren? Delphi 5 erstellt immer die Wrapper-Klasse wo ich TPackage = class(TOleServer) habe, kann ich von dem etwas ableiten, oder mu� ich alles mit TAutoObjectFactory.Create(...ciMultiInstance) machen
und TDTSPack = class(TAutoObject,_Package) und alle Prozeduren neu implementieren. Nachdem in einem Package die Transaktionen in Threads ausgef�hrt werden, so werden mehrere (eingstellt 4) Transaktionen auf einmal gestartet. Mu� ich dann an meinen Event-Interface auch was �ndern?
Ich hoffe, da� ich halbwegs verst�ndlich mein Problem geschildert habe. Ich w�rde mich f�r eine kleine Hilfe sehr bedanken.


Danke
Balazs

ps. Was ist das unterschied zwischen TComObjectFactory und TAutoObjectFactory?
</p&gt

**Andreas Kosch** · 08.03.2000, 12:12

Hallo,

das DTSPackage object (Data Transformation Services Package Object) wird mit dem Threading-Modell Both installiert. Somit kann dieses Objekt entweder im STA oder im MTA ausgef�hrt werden. F�r die Zustellung der Events ruft dieses Objekt das Sink-Objekt im Client (also der Delphi-Anwendung) auf. Je nach dem aktuellen Apartment des DTSPackage-Objekts muss COM spezielle Anpassungen vornehmen, um die beiden beteiligten Apartments anzupassen.

Wenn die von Delphi generierte VCL-Wrapperkomponente im Formular plaziert wird, wird das Sink-Objekt bei der Standardkonfiguration im STA0 (Single Threaded Apartment des prim�ren Thread)
ausgef�hrt. Wenn nun dieses Sink-Objekt von einem DTSPackage-Objekt aufgerufen wird, das in einem MTA (Multi Threaded Apartment) "lebt", muss COM �ber das Proxy-Objekt die Kompatibilit�t herstellen. Dies
f�hrt dazu, das der Aufruf als Windows-Botschaft einem versteckten Hilfsfenster zugeschickt wird. Und somit besteht die Gefahr von blockierenden Anwendungen, wenn die beteiligten Botschaftswarteschlangen nicht mehr regelm�ssig aufgerufen werden k�nnen. Daher war meine erste Frage (siehe 01.03.) auch nach einem modalen Dialog. Um nun zu pr�fen, ob es an der Botschaftswarteschlange liegt, w�rde ich in den
Ereignisbehandlungsmethoden f�r das Event nur eine private Botschaft �ber PostMessage an das eigene Hauptformular schicken. Da PostMessage nur eine Botschaft in die Warteschlange ablegt, kann die Event-Methode sofort zur�ckkehren, ohne das VCL-Aufrufe im prim�ren Thread stattfinden.

Wenn das erfolgreich ist, gibt es 2 M�glichkeiten: 

1. Das eigene Sink-Objekt muss in einem MTA ausgef�hrt werden (vorher aber das Kleingedruckte genau durchlesen):

<pre>
begin
{$IFDEF MultiThreadedServer}
IsMultiThread:= True;
CoInitFlags := COINIT_MULTITHREADED;
{$ENDIF}
Application.Initialize;
Application.CreateForm(TFormMain2, FormMain2);
Application.Run;
end.
</pre>

2. Das eigene Sink-Objekt darf nicht im STA0 des prim�ren Threads (VCL) laufen, sondern muss in eigenem eigenen STA ausgef�hrt werden. Das folgende Beispiel spaltet zu Beispiel einen separaten Thread ab und f�hrt dort eine Instanz von TWordApplication (dem VCL-Wrapper f�r das Word-Application-Objekt) aus:

<pre>
type
TForm1 = class(TForm)
ListBox1: TListBox;
Button1: TButton;
procedure Button1Click(Sender: TObject);
end;

TWrdObjThread = class(TThread)
private
FText : String;
procedure UpdateFrm;
procedure WrdAppQuit(Sender: TObject);
protected
procedure Execute; override;
public
constructor Create(Text: String);
end;

var
Form1: TForm1;

implementation

{$R *.DFM}

uses ComObj, ActiveX;

constructor TWrdObjThread.Create(Text: String);
begin
inherited Create(False);
FreeOnTerminate := True;
FText := Text;
end;

procedure TWrdObjThread.Execute;
var
aThrdWordApp : TWordApplication;
vSaveChanges : OleVariant;
begin
OleCheck(CoInitialize(nil));
try
aThrdWordApp := TWordApplication.Create(nil);
try
aThrdWordApp.OnQuit := WrdAppQuit;
aThrdWordApp.Connect;
FText := aThrdWordApp.Version;
Synchronize(UpdateFrm);
aThrdWordApp.Quit(vSaveChanges);
aThrdWordApp.Disconnect;
finally
aThrdWordApp.Free;
end;
finally
CoUninitialize;
end;
end;

procedure TWrdObjThread.WrdAppQuit(Sender: TObject);
begin
Form1.ListBox1.Items.Add('WordApplication: Quit');
end;

procedure TWrdObjThread.UpdateFrm;
begin
Form1.ListBox1.Items.Add('Testeintrag aus dem Thread: ' + FText);
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
TWrdObjThread.Create('Test');
end;
</pre&gt

08.03.2000, 18:51

Hallo Herr Kosch,

danke f�r die ausf�hrliche Beschreibung.
Ich habe wahrscheinlich vergessen zu schreiben, dass die Delphi erstellte DTS-Komponent nicht richtig funktioniert. (Bei mir!)
Wenn ich das Package ausf�hren (aPack.execute) will, dann erhalte ich immer eine Exception-Access-Violation,
deshalb mu� ich mit CoPackage.create arbeiten. Ich wei� leider nicht, wieso immer diese Fehlermeldung
kommt. Jetzt habe ich es auch in dem Thread ausprobiert, die Fehlermeldung erhalte ich weiterhin.

Bisher habe ich mit CoPackage und DTS-Event Komponent gearbeitet.

... 
procedure TDTSThread.Execute; 
var aPack:_Package; 
  aPunk:OleVariant; 
  aPackEvent:TPackageEvents; 
begin 
  OleCheck(CoInitialize(nil)); 
  try 
  aPack:=CoPackage.Create; 
  //aPack:=TPackage.Create(nil); 
  aPackEvent:=TPackageEvents.Create(nil); 
  try 
  //aPack.OnFinish:=DtsPackFinish; 
  aPack.LoadFromSQLServer(cServername,cServerPasswor d,'',DTSSQLStgFlag_Default,'','','',cPackageName,a punk); 
  aPackEvent.Connect(aPack as IUnknown); 
  aPackEvent.OnFinish:=DtsPackFinish; 

  aPack.Execute; 
  Synchronize(WorkDone); 
  finally 
  end; 
  finally 
  CoUninitialize; 
  end; 
end; 


procedure TDTSThread.WorkDone; 
begin 
  Form1.ListBox1.Items.Add(FText); 
end; 


function TDTSThread.DtsPackFinish(Sender: TObject; 
const EventSource: WideString):HRESULT; 
begin 
  Form1.ListBox1.Items.Add('FERTIG'); 
  MakeResult(0, FACILITY_NULL, S_OK); 
end 



Diese Variante l�uft schon besser, nachdem der Package aber eine neue STEP ausf�hren will bricht das Programm mit der folgende Fehlermeldung ab
OleException: Ausf�hrung wurde von Benutzer abgrebrochen.
Dieselbe Fehlermeldung erhalte ich auch in Visula Basic.

Ohne Thread habe ich auch die PostMessage in einer Ereginisbehandlung ausprobiert, das Programm ist trotzdem angehalten.


mfg und danke 
Balaz

**B. Petenyi** · 08.03.2000, 19:59

Wenn in der Ereignisbehandlungsmethode nur eine private PostMessage-Befehl steht, erhalte ich genauso die Fehlermeldung:
 
OleException: Ausf�hrung wurde von Benutzer abgrebroche

**Andreas Kosch** · 09.03.2000, 08:46

Hallo,

nicht ohne Grund habe ich in meinem Beispiel die TWordApplication-Komponente verwendet ;-) 
Wenn dieser Fehler auch in Visual Basic auftritt, scheint die Macke im DTSPackage-Objekt zu liegen bzw. man h�lt sich nicht an die von MS vorgeschriebenen Aufruf-Umgebungsbedingungen (sollte in der Dokumentation zu DTSPackage zu finden sein. Die Umfangreichen Abhandlungen zum Package Objects (DTS) aus dem SQL Server Online-Handbuch habe ich noch nicht gelesen - da ich dieses Objekt bisher noch nicht eingesetzt habe.

Solange diese Fehler auftreten, macht es keinen Sinn, weiter mit Threads und Apartments zu experimentieren.

Ich w�rde zuerst versuchen, das Event OnError auszuwerten, um genauere Angaben �ber die Gr�nde des DTSPackage-Vetos zu erhalten. Ausserdem kann man dort festlegen, ob die Ausf�hrung abgebrochen werden soll oder nicht:

Use the Cancel argument to direct package execution on error. When Cancel is True (default), execution of the package is terminated on return from the application error handler. When Cancel is False, DTS attempts to execute the next task indicated.</i&gt

Announcement

CriticalSection-Problem

CriticalSection-Problem

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment