Announcement

**Mario.Noack** · 28.02.2002, 12:35

.. ich habe es etwas einschränken können: 
Ich habe eine Master-Detailbeziehung. Wenn ich in der Detailtabelle Änderungen speichere und dann die Mastertabelle Editieren will, kommt der Fehler. Schliesse ich vor dem Editieren der Mastertabelle die Detailtabelle, geht es problemlos.
Damit weiß ich zwar, wie ich das Problem umschiffen kann, aber ob mir das dauerhaft hilft, weiß ich nicht.
Schöne Grüße, Mario Noac

**Mario.Noack** · 28.02.2002, 18:07

object Form1: TForm1 
Left = 227 
Top = 107 
Width = 870 
Height = 640 
Caption = 'Form1' 
Color = clBtnFace 
Font.Charset = DEFAULT_CHARSET 
Font.Color = clWindowText 
Font.Height = -11 
Font.Name = 'MS Sans Serif' 
Font.Style = [] 
OldCreateOrder = False 
PixelsPerInch = 96 
TextHeight = 13 
object DBGrid1: TDBGrid 
Left = 255 
Top = 3 
Width = 577 
Height = 274 
DataSource = DataSource1 
TabOrder = 0 
TitleFont.Charset = DEFAULT_CHARSET 
TitleFont.Color = clWindowText 
TitleFont.Height = -11 
TitleFont.Name = 'MS Sans Serif' 
TitleFont.Style = [] 
end 
object DBGrid2: TDBGrid 
Left = 261 
Top = 285 
Width = 581 
Height = 327 
DataSource = DataSource2 
TabOrder = 1 
TitleFont.Charset = DEFAULT_CHARSET 
TitleFont.Color = clWindowText 
TitleFont.Height = -11 
TitleFont.Name = 'MS Sans Serif' 
TitleFont.Style = [] 
end 
object DBNavigator1: TDBNavigator 
Left = 6 
Top = 3 
Width = 240 
Height = 25 
DataSource = DataSource1 
TabOrder = 2 
end 
object DBNavigator2: TDBNavigator 
Left = 12 
Top = 291 
Width = 240 
Height = 25 
DataSource = DataSource2 
TabOrder = 3 
end 
object Button1: TButton 
Left = 96 
Top = 432 
Width = 75 
Height = 25 
Caption = 'Button1' 
TabOrder = 4 
OnClick = Button1Click 
end 
object ADOConnection1: TADOConnection 
Connected = True 
ConnectionString = 
'Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security In' + 
'fo=False;Initial Catalog=Northwind;Data Source=ntsql' 
LoginPrompt = False 
Provider = 'SQLOLEDB.1' 
Left = 12 
Top = 27 
end 
object ADODataSet1: TADODataSet 
Active = True 
Connection = ADOConnection1 
CursorLocation = clUseServer 
CommandText = 'select * from Orders' 
Parameters = <> 
Left = 45 
Top = 27 
end 
object ADODataSet2: TADODataSet 
Active = True 
Connection = ADOConnection1 
CursorLocation = clUseServer 
CommandText = 'select * from [Order Details]'#13#10'where OrderID=:ORDERID' 
DataSource = DataSource1 
MasterFields = 'ORDERID' 
Parameters = < 
item 
Name = 'ORDERID' 
Attributes = [paSigned] 
DataType = ftInteger 
Precision = 10 
Value = 10260 
end> 
Left = 42 
Top = 60 
end 
object DataSource1: TDataSource 
DataSet = ADODataSet1 
Left = 75 
Top = 27 
end 
object DataSource2: TDataSource 
DataSet = ADODataSet2 
Left = 75 
Top = 60 
end 
end 
&#10

**Mario.Noack** · 28.02.2002, 18:12

unit Unit1;
interface
uses 
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, 
Dialogs, Grids, DBGrids, DB, ADODB, ExtCtrls, DBCtrls, StdCtrls;
type 
TForm1 = class(TForm) 
ADOConnection1: TADOConnection; 
ADODataSet1: TADODataSet; 
ADODataSet2: TADODataSet; 
DataSource1: TDataSource; 
DataSource2: TDataSource; 
DBGrid1: TDBGrid; 
DBGrid2: TDBGrid; 
DBNavigator1: TDBNavigator; 
DBNavigator2: TDBNavigator; 
Button1: TButton; 
procedure Button1Click(Sender: TObject); 
private 
{ Private-Deklarationen } 
public 
{ Public-Deklarationen } 
end;
var 
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.Button1Click(Sender:
TObject); 
begin 
ADODataSet2.Append; 
ADODataSet2.FieldByName('ProductID').Value := '43'; 
ADODataSet2.Post;
 ADODataSet2.Locate('PRODUCTID','11',[]);
// ADODataSet2.Close; 
// ADODataSet2.Open;
 ADODataSet1.Edit; 
end;
end.
 
So, nun habe ich das Problem an der Datenbank Northwind vom SQL2000
Server von MS endlich reproduzieren können. Wäre echt nett, wenn mir
dass mal jemand gedanklich nachvollziehen könnte. Es müsste eigentlich
im DFM-Source nur der Server geändert werden, auf den tatsächlich
vorhandenen Servernamen.
Gedacht hatte ich es mir eigentlich so: Detailsatz wird angelegt und dann wird
auf einen (im allgemein den gerade angelegten) Datensatz positioniert. Das ganze
geschieht mit Locate und genau das ist das Problem. Wird Locate weggelassen,
funzt alles wunderbar. Ansonsten kommt halt die abstruse Fehlermeldung. Das Problem kommt bei mir unter Win2k SP2 mit Ado 2.6 und Ado 2.7 sowohl unter D5 sowie D6.
Vielen Dank schon mal für Eure Mühen, Mario Noack</p&gt

**Mario.Noack** · 28.02.2002, 18:43

type 
 TMyAdoDataSet = Class(TAdoDataSet) 
END; 
procedure TForm1.Button1Click(Sender:
TObject); 
begin 
ADODataSet2.Append; 
ADODataSet2.FieldByName('ProductID').Value := '43'; 
ADODataSet2.Post;
 ADODataSet2.Locate('PRODUCTID','11',[]); 
TMyAdoDataSet(ADODataSet2).Destroy LookupCursor;
 ADODataSet1.Edit; 
end; 
 
So geht's!! Aber dass das in D5 und D6 vergessen wurde, glaube ich fast nicht,
weiß jemand vielleicht, ob ich nur eine falsche Herangehensweise an den
Tag lege?
Schöne Grüße, Mario Noack</p&gt

**Andreas Kosch** · 01.03.2002, 09:42

Hallo,

das Grundproblem liegt an der Konfiguration clUseServer für die TADODataSet-Komponenten. Beide Komponenten fordern einen Server-seitigen Cursor über die gleiche TADOConnection-Verbindung an. Bei einem Client-seitigen Cursor (clUseClient) trennt ADO den nativen Datenbank-Cursor sofort wieder, nachdem alle Datensätze der Ergebnismenge beim Öffnen sofort zum Client transportiert wurden. Die Datenbankverbindung ist danach sofort wieder "frei", so dass andere Aktionen völlig ohne Kollisionsrisiko über die gleiche Verbindung ausgeführt werden dürfen.

Bei der Konfiguration clUseServer muss man hingegen damit rechnen, dass die Datenbankverbindung für längere Zeit blockiert bleibt und somit keine andere Aktion zulässig ist. Wenn eine Anwendung mehrere Datenmengen öffnen, die die Einstellungen server-seitiger Cursor, Forward-Only und Read-Only (Firehouse-Cursor) verwenden, so wird nur die erste Datenmenge über die Connection-Instanz verwaltet. Für alle anderen Datenmengen erstellt ADO automatisch im Hintergrund zusätzliche Verbindungen. Dies ist in dem o.g. Beispiel jedoch nicht der Fall (Locktyp = ltOptimistic) - daher auch das Problem. Microsoft hat dazu in seiner Knowlegde Base den Artikel Q235282 "INFO: SQL Server Spawns Additional Connections When You Open Multiple ForwardOnly ADO Recordsets" veröffentlicht.

>Das ganze geschieht mit Locate und genau das ist das Problem.

Auf Locate würde ich sowieso generell bei ADO verzichten - denn hinter Locate steckt keine native ADO-Methode, sondern Borland verzweigt innerhalb der Locate-Methode entweder zu Find oder zu Filter. Es ist daher besser und effektiver, gleich eine der beiden Methoden zu verwenden - zumal wir dann entscheiden können, welcher Suchweg im Einzelfall besser ist.

P.S: Für ADO gilt die folgende Fausregel für die Eigenschaft CursorLocation: 
- MS ACCESS-Datenbank: clUseServer 
- MS SQL Server-Datenbank: clUseClient
&#10

**Mario.Noack** · 01.03.2002, 10:06

Hallo Andreas,
ganz verstehe ich das noch nicht, wir verwenden eigentlich einen ctKeyset Cursor. Zudem bezieht sich Q235282 auch nur auf SQL 6.5 und 7.0. Aber das muss ja nichts heißen, 8.0 wird ja auch nicht explizit ausgeschlossen. Auf alle Fälle kommt clUseClient aus verschiedenen Gründen im Moment leider nicht in Frage.
Aber hier noch eine Frage: Ich kann zwar mit der nativen Methode Find suchen, jedoch wie positioniere ich dann meine Table bzw. DataSource nach. Diese ist ja für die Visualisierung unverzichtbar? Kannst Du da vielleicht mal ein Beispiel machen?
Vielen Dank, Mario Noac

**Andreas Kosch** · 01.03.2002, 11:56

Hallo,

>...wie positioniere ich dann meine Table bzw. DataSource nach?

Das Recordset-Objekt stellt die Methode Find zur Verfügung, um einen bestimmten Datensatz in der Ergebnismenge lokalisieren zu können. Diese Methode steht bei client-seitigen Cursors (clUseClient) immer zur Verfügung und bei den serverseitigen Cursors nur dann, wenn die restlichen Konfigurationen die Unterstützung von Bookmarks erlauben. Immer dann, wenn Find bei clientseitigen Cursorn aufgerufen wird, erzeugt ADO über die OLE DB Client Cursor Engine einen internen Index für das Feld, das in dem Suchbegriff referenziert wird. Aus diesem Grund bietet die Methode Find auch die Option an, als zweiten Parameter die Anzahl der zu überspringenden Datensätze zu übergeben, so dass die erneute Suche erst nach dieser Datensatzposition gestartet wird. Wenn zum Beispiel alle Kunden aus der Stadt London ermittelt werden sollen, könnte die Suche über die Methode Find zum Beispiel so aussehen. Über den Aufruf der TADODataSet-Methode Resync sorge ich dafür, dass die von der Recordset-Methode Find gefundenen Datensätze auch im TDBGrid als aktuelle Datensätze dargestellt werden (hinter FRSFind verbirgt sich ein privates Objektfeld des Formulars vom Typ _Recordset).
<pre>
procedure TForm1.ButtonFindClick(Sender: TObject);
begin
FRSFind := ADODataSet1.Recordset;
FRSFind.Find(Format('City = %s', [QuotedStr(EditLocate.Text)]),
0, adSearchForward, EmptyParam);
ADODataSet1.Resync([rmExact]);
end;

procedure TForm1.ButtonFindNextClick(Sender: TObject);
begin
FRSFind.Find(Format('City = %s', [QuotedStr(EditLocate.Text)]),
1, adSearchForward, EmptyParam);
if FRSFind.EOF then begin
ShowMessage('Keine weiteren Fundstellen');
FRSFind.MoveFirst;
end;
ADODataSet1.Resync([rmExact]);
end;
</pre>
Wird beim nächsten Aufruf von Find als zweiter Parameter der Wert 1 übergeben, so überspringt ADO den aktuellen Datensatz (also die letzte Fundstelle), so dass die Methode Find die nächste Fundstelle positioniert ( = Ersatz für die fehlende Methode FindNext).

>ganz verstehe ich das noch nicht, wir verwenden eigentlich einen ctKeyset Cursor

Da Haken liegt beim fehlenden Locktype ltReadOnly. Nur dann, wenn es sich um eine Read-Only-Datenmenge handelt (bei der keine Update-Zugriffe über eine Transaktion möglich sind), darf ADO ungestraft im Hintergrund automatisch eine neue Verbindung (Connection) zur Datenbank aufbauen. Da die Datenmenge aber editierbar sein soll, ist dies nicht erlaubt (um kein Transaktions-Chaos zu provozieren).

>Auf alle Fälle kommt clUseClient aus verschiedenen Gründen im Moment leider nicht in Frage.

In diesem Fall muss man selbst mehrere TADOConnections vorsehen und die Datenmengen (TADODataSets) voneinander abschotten, indem diese verschiedenen Verbindungen zugeordnet werden.

P.S: Es ist wie beim Telefon: Wenn ein Familienmitglied als "Quasselstrippe" stundenlang mit der besten Freundin telefoniert, muss man a) entweder warten oder b) zu IDSN greifen - weil man dort ne 2. Nummer + Leitung hat :-

Announcement

Fehlermeldung: Objekt war geöffnet

Fehlermeldung: Objekt war geöffnet

Comment

Comment

Comment

Comment

Comment

Comment

Comment