Recordset ist "nur lesen" Warum?

[Bernd Schulz]

Hi!<br>
Die "beste" Konstellation ist (wie im Forum zu lesen) eine Kombination aus TADODataSet und TADOCommand.<br>
Wenn ich aber jetzt folgenden Code ausführe erhalte ich immer ein "nur lesen" Recordset:<br>
ADOCommand1.commandText := 'Select * from adressen where adressnr = :Adressnr';<br>
ADOCommand1.parameters[0].value := '4711';<br>
ADODataSet1.active := false;<br>
ADODataSet1.LockType := ltBatchOptimistic;<br>
ADODataSet1.RecordSet := ADOCommand1.execute;<br>
ADODataSet1.active := true;<br>
<br>
Ist das Umfeld das Problem? InterBase mit easysoft ODBC Treiber? Wenn ja wie kann man das umgehen?!?<br>
Dank im Voraus! BYE BERND<br>

[BlueBit]

Hallo Bernd,

AdoCommand sollte eigentlich nur verwendet wenn Strukturupdates anstehen. Für die Datenverarbeitung sollte man ausschließlich AdoDataSet einsetzen.

AdoDataSet:

<pre>

AdoDataSet1.CommandText := 'Select * from adressen where adressnr = :Adressnr'
AdoDataSet1.CommandType := Text
AdoDataSet1.Connection := //Deine Connection

SQL:
select Id, Bezeichnung, Steuersatz
from Mehrwertsteuer
where Bezeichnung = :Bez
------------------------------------------
Source:
function TxdmFunctions1.GetSteuer(Bezeichnung : String): single;
begin
with fuMwSt do
try
close;
Parameters[0].Value := Bezeichnung;
open;

if RecordCount > 0 then
begin
First;
Result := fuMwStSteuersatz.Value;
end
else Result := 0;
finally
Close;
end;
end;

Gruß Mathia

[Bernd Schulz]

Hi!<br>
Habe ich dann noch den "Komfort" von ADO mit Abtrennung vom Netz (Briefcase)?<br>
Ich bin mir fast sicher das hier im Forum anders gelesen zu haben.<br>
<br>
BYE BERN

[BlueBit]

Hallo,

das mit der Abtrennung vom Netz habe ich nicht mitbekommen. Weis nicht genau wie Du das meinst. Aber AdoCommand ist äher für SQL - Befehle in der Form: Create, Grant, Revoke, Drop oder eben für den Aufruf serverseitiger Prozeduren geeignet. Wenn man Daten verarbeiten möchte, gibt es nichts besseres als AdoDataSet. Da diese Componente über die volle ADO - Inplementierung verfügt (TAdoDataSet.RecordSet).
Somit kann bei eventuellen Problemen immer noch ein wenig tiefer in das ADO - System vordringen.

Grüe Mathia

[Bernd Schulz]

Hi!<br>
Das "Briefcase" Moell sieht vor, daß ich mir den Recordset auf den Client holen kann, die Verbindung zum Netz lösen kann (Außendiensmitarbeiter) und später nach der Wiederanmeldung am Netz die geänderten Daten auf den SQl Server zurück spielen kann.<br>
Geht das auch mit der Implementierung ohne ADOCommand?<br>
Siehr Dir mal bitte den Eintrag<br>
<a href="/webx?50@@.ee87146">Adi Emmenegger "TADODataSet mit TADOCommand > "nur Lesen"-Modus, warum ?" 06.09.2001 14:52</a><br>
hier im Forum an. Ist eigentlich genau mein Problem. Ähm nur mit der Antwort von Herrn Kosch komme ich nicht klar. Ich setze explizit ltOptimisticLocking und trotzdem "nur lesen".<br>
BYE BERND<br&gt

[Andreas Kosch]

Hallo,

generell spielt es für ADO (und das RecordSet-Objekt) keine Rolle, woher die Datenmenge kommt. Die nativen ADO-Objekte unterliegen an dieser Stellen keinen Einschränkungen. Im Gegensatz dazu bilden die ADO Express-Komponenten von Borland nicht alle diese Möglichkeiten ab. Zum Beispiel kann man bei TADOCommand die Eigenschaft LockType nicht konfigurieren, so dass <b>ltBatchOptimistic</b> nicht über den Objektinspektor definiert werden kann. Wichtig ist, dass dieser Wert gesetzt werden muss, <b>bevor</b> die Ergebnismenge im RecordSet abgelegt wird, daher ist die Zuweisung <b>nach</b> dem Ausführen von TADOCommand zu spät, um berücksichtigt zu werden. Wenn ADO Express genutzt werden soll, muss man an dieser Stelle zu TADODataSet greifen:

Beispieldatenbank für den Microsoft SQL Server 2000:
<pre>
USE tempdb
GO

CREATE TABLE Adressen (
AdressNr INTEGER NOT NULL PRIMARY KEY,
Wert VARCHAR(10))
GO

INSERT INTO Adressen (AdressNr, Wert) VALUES (1,'Test');
GO
</pre>
Zugriff im Programm:
<pre>
object Form1: TForm1
Left = 298
Top = 115
Width = 696
Height = 480
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 = 16
Top = 96
Width = 320
Height = 120
DataSource = DataSource1
TabOrder = 0
TitleFont.Charset = DEFAULT_CHARSET
TitleFont.Color = clWindowText
TitleFont.Height = -11
TitleFont.Name = 'MS Sans Serif'
TitleFont.Style = []
end
object DBNavigator1: TDBNavigator
Left = 16
Top = 56
Width = 240
Height = 25
DataSource = DataSource1
TabOrder = 1
end
object ADOConnection1: TADOConnection
Connected = True
ConnectionString =
'Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security In' +
'fo=False;Initial Catalog=tempdb;Data Source=(local)'
LoginPrompt = False
Provider = 'SQLOLEDB.1'
Left = 16
Top = 8
end
object ADODataSet1: TADODataSet
Active = True
Connection = ADOConnection1
CursorType = ctStatic
LockType = ltBatchOptimistic
CommandText =
'select AdressNr, Wert from Adressen'#13#10'where AdressNr = :AdressNr'#13 +
#10
Parameters = <
item
Name = 'AdressNr'
Attributes = [paSigned]
DataType = ftInteger
Precision = 10
Size = 4
Value = 1
end>
Left = 56
Top = 8
end
object DataSource1: TDataSource
DataSet = ADODataSet1
Left = 96
Top = 8
end
end
</pre>
Wenn man direkt mit den nativen ADO-Objekten (Command und Recordset) arbeitet, gelten diese Beschränkungen nicht, wie das folgende Beispiel demonstriert:
<pre>
...
aCommand := CoCommand.Create;
...
aRS := CoRecordset.Create;
aRS.Set_ActiveConnection(aConnection);
aRS.CursorLocation := adUseClient;
// Parametisierte SELECT-Abfrage über das Command-Objekt ausführen, Ergebnissmenge abholen
aRS.Open(aCommand, EmptyParam, adUseClient,
adLockBatchOptimistic, adOptionUnspecified);
...
</pre>

[Bernd Schulz]

Hi!<br>
Aaaaah!<br>
Wieder erhellt sich ein dunkler Raum!!!!<br>
Danke jetzt ist's klar.<br>
BYE BERND<br&gt