Locate tut nicht das was es soll

[Peter A. Smolik]

Hallo Freunde,

Ich hab geglaubt ich trau meine augen nicht. ich konvertiere alle DBAse Daten nach Access und dabei ändert sich auch noch die Struktur.

Dabei hab ich eine Tabelle: (ADOTable1)

KnotenName; feld1; feld2 ;feld3

Records: z.B.
verdeckt;bla;bla;bla
Verdeckt;bla;bla;bla
M19991;bla;bla;bla
M199910;bla;bla;bla

BITTE BEACHTET DIE GROSS- KLEINSCHREIBUNG!!!

Also ich geh her und mache
strVar= einmal 'verdeckt' und einmal 'M19991'
if ADOTABLE1.LOCATE('KnotenName',StrVar,[]) then
begin
ADOTABLE2.Insert.....

[] damit nur der explizite Datensatz gefunden wird

und was bekomme ich als Ergebenis den Datensatz
Verdeckt (weil er in der Datenbank vorne steht
und
M199910 (ebenso)

Kann mir das einer erklären??????
Hab mich mein Delphi-Leben lang auf das Locate verlassen aber jetzt??.
Wollte es mit SEEK probieren aber da bekomm ich nur die Fehler meldung der Provider läßt diese Aktion nicht zu;

Für dringende Hilfe dankbar

Euer

Peter

[Bernhard Geyer]

Ich hab jetzt auf meine Access-Datenbank ein Query durchgeführt, welche mittels "WHERE Spalte = Wert" eine Abfrage startet.<br>
Access unterscheidet (in der Standardeinstellung) nicht zwischen Groß- und Kleinschreiung. Also wenn Du nach 'verdeckt' suchst, bekommst Du sowohl 'verdeckt' als auch 'Verdeckt'. Und da die Reihenfolge wie die Datensätze hochkommen nicht festgelegt ist, kann bei Locate sowohl 'verdeckt' als auch 'Verdeckt' als aktueller Datensatz zurückkommen. Ich weiß leider nicht, ob man Access zu einer unterscheidung zwischen Groß- und Kleinschreibung überreden kann

[Andreas Kosch]

Hallo,

&gt;Wollte es mit SEEK probieren aber da bekomm ich nur die Fehlermeldung der Provider läßt diese Aktion nicht zu.

über die Recordset-Eigenschaft <b>Supports</b> kann man nachschauen, welche Funktionen in der aktuellen Konfiguration zur Verfügung stehen. Im Fall von ACCESS-Datenbanken steht <b>Seek</b> nur dann zur Verfügung, wenn die Kombination von <b>clUseServer</b> und <b>cmdTableDirect</b> verwendet wird.

Im Fall der Suche nach der exakten Schreibweise kann ich nur mit einem Beispiel für den Microsoft SQL Server 2000 dienen (ACCESS-Datenbanken verwendet ich nur als Transportmittel bzw. für lokal zu speichernde temporäre Daten):
<pre>
SELECT * FROM Customers
WHERE
CAST(LastName AS VARBINARY(10)) = CAST('ritz' AS VARBINARY(10))
</pre>
P.S: Die Delphi-Methode Locate ist unter ADO nur 2. Wahl, besser ist <b>Find</b> oder <b>Filter</b> geeignet

[Peter A. Smolik]

hallo,

also ich hab das ausprobiert:

die Filtermethode unterscheidet auch nicht zwischen Groß und Kleinschreibung, wenigsten erkennt sie das M91110 und M9111 nicht das gleiche ist.

Seit mir bitte nicht böse aber:

1. Stimmt der Online Hilfe Text dann nicht denn was Locate macht oder
nicht ist eindeutig definiert.
2. kann mann dann aus einer Access Datenbank keine Datenfilter bei
denen man nicht gewährleisten kann das es einen solchen Fall nicht
gibt.
3. Das ganz Locate und Filterkonzept wird damit ad adsurdum geführt.

Ich hab das auch mit dem Seek clUseServer und cmdTableDirect ausprobiert. Das cmdTableDirect läßt er zu aber wenn ich auf clUseServer benutze und auf aktiv gehe bekomme ich die leibe Feldermeldung :

"Das Object oder der Provider kann den angorderten Vorgang nicht ausführen."

Also ich weis mir keinen Rat mehr.
Vorallem versteh ich nicht wie man sowas verkaufen kann.
Übrigens hab ich das gleiche Ergebnis wenn ich das ganze in reines SQL verpacke statt einem DS bekomme ich zwei.

Euer schwer entäuschter

Pete

[Bernhard Geyer]

Das bei Access die Locate-Methode nicht richtig funktioniert, liegt aber an der fehlenden unterscheidung zwischen Groß und Kleinschreibung bei Access. Delphi (bzw. ADOExpress) führt das Locate nicht selber durch, sondern bemüht hier ADO direkt und damit den Access-Treiber. Und wenn der groß und kleinschreibung nicht unterscheidet kann Delphi hier nix machen.

Wenn Du deine Datenbank von einer Datenbank (DBase) welche Groß/Kleinschreibung hier unterscheidet, auf eine Datenbank (Access) wechselt, welche diese nicht tut, so mußt Du entsprechend dein Programm anpassen, das die fehlende unterscheidung nicht mehr stört

[Andreas Kosch]

Hallo,

&gt;1. Stimmt der Online Hilfe Text dann nicht denn was Locate macht oder nicht ist eindeutig definiert.

hinter den ADO Express-Komponenten von Delphi steckt nur eine "Umverpackung" für die nativen ADO-Objekte von Microsoft. Und die ADO-Objekte (COM-Objekte) von Microsoft greifen nur über die zuständigen OLE DB Provider auf die Datenbank zu. Wie bei jeder Kette bestimmt das "schwächste Glied" (OLE DB Provider -> ADO -> ADO Express) das Gesamtverhalten.

In ADO gibt es keine Methode Locate, so dass ADO Express diese Methode <b>simulieren</b> muss, indem intern je nach vorgefundenem Fall zwischen Find und Filter gewechselt wird. Borland hat Locate nur in ADO Express nachgerüstet, damit der Umstieg von der BDE leichter fällt.

Wie mein Beispiel mit dem Microsoft SQL Server demonstriert, ist ADO durchaus in der Lage, die gesuchte Info zu liefern (wenn die Datenbank und der OLE DB Provider dies unterstützt).

Das folgende Beispiel demonstriert den Aufruf von <b>Seek</b> im Zusammenhang mit einer ACCESS-Datenbank:
<pre>
procedure TForm1.ButtonSeekClick(Sender: TObject);
begin
ADODataSet1.Seek(EditName.Text)
end;

procedure TForm1.ButtonSeekLastClick(Sender: TObject);
begin
ADODataSet1.Seek(EditName.Text, soLastEQ)
end;

procedure TForm1.ButtonSeekBeforeClick(Sender: TObject);
begin
ADODataSet1.Seek(EditName.Text, soBeforeEQ)
end;
</pre>
Im Objektinspektor ist dafür die folgende Konfiguration notwendig:
<pre>
object ADOConnection1: TADOConnection
Connected = True
ConnectionString =
'Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Buch\ADO\CDROM\D' +
'atabase\dbdemos.mdb;Persist Security Info=False'
CursorLocation = clUseServer
LoginPrompt = False
Mode = cmShareDenyNone
Provider = 'Microsoft.Jet.OLEDB.4.0'
Left = 136
Top = 96
end
object ADODataSet1: TADODataSet
Active = True
Connection = ADOConnection1
CursorLocation = clUseServer
CommandText = 'employee'
CommandType = cmdTableDirect
IndexName = 'ByName'
Parameters = <>
Left = 168
Top = 96
object ADODataSet1EmpNo: TIntegerField
DisplayWidth = 6
FieldName = 'EmpNo'
end
object ADODataSet1LastName: TWideStringField
DisplayWidth = 17
FieldName = 'LastName'
end
object ADODataSet1FirstName: TWideStringField
FieldName = 'FirstName'
Size = 15
end
object ADODataSet1PhoneExt: TWideStringField
FieldName = 'PhoneExt'
Size = 4
end
object ADODataSet1HireDate: TDateTimeField
FieldName = 'HireDate'
end
object ADODataSet1Salary: TFloatField
FieldName = 'Salary'
end
end
object DataSource1: TDataSource
DataSet = ADODataSet1
Left = 200
Top = 96
end
</pre>
Damit Seek problemlos arbeiten kann, muss die Datenmenge über <b>IndexName</b> die Sortierreihenfolge festlegen.

&gt;Übrigens hab ich das gleiche Ergebnis wenn ich das ganze in reines SQL verpacke statt einem DS bekomme ich zwei.

In diesem Fall hat die ACCESS-Tabelle entweder keinen Primärschlüssel (ganz schlechte Idee) oder die SELECT-Abfrage verwendet eine ungeeignete WHERE-Einschränkung