Announcement

**Andreas Kosch** · 20.10.1999, 04:55

Hallo,

ich vermute einmal, das eine Paradox-Datenbank (..AUTOINC, User-DB...) verwendet und auf diese �ber eine 32-Bit-Version der BDE zugegriffen wird. Trotzdem habe ich noch weitere Fragen: 
1. Wie sieht der Fehlermeldungsdialog SHARE FEHLER aus (d.h. stammt er vom Programm oder kommt er direkt von Win32)? 
2. Wird in der Anwendung eine SELECT-Abfrage via TQuery verwendet? 
3. Wie wird im Programm die Session-Eigenschaft PrivateDir konfiguriert? 
4. Verschwindet die Fehlermeldung, wenn f�r die BDE die Eigenschaft LOCAL SHARE aktiviert wird? 
5. Verwenden alle Clients tats�chlich einen gemeinsamen (identischen) Wert f�r die BDE-Eigenschaft NET DIR? 
6. Tauchen beim Zugriff auf gro�e Memo-Daten tempor�re Tabellen im PrivateDir-Verzeichnis auf? 

Wenn ich die Stichw�rter Exclusiver Tabellenzugriff und Zugriff vom lokalen Rechner aus h�re, f�llt mir spontan eine der BDE-Performanceoptimierungen ein (Einsparen von Dateisperren). Werden dann allerdings mehrere Programminstanzen auf dem gleichen Rechner gestartet, die alle das gleiche PrivateDir verwenden, k�nne das geschilderte Problem auftreten

**JHoyer** · 20.10.1999, 08:09

Ich vermute einmal, das eine Paradox-Datenbank (..AUTOINC, User-DB...)
verwendet und auf diese �ber eine 32-Bit-Version der BDE zugegriffen
wird.

Das ist richtig!

1. Wie sieht der Fehlermeldungsdialog SHARE FEHLER aus (d.h. stammt er
vom Programm oder kommt er direkt von Win32)?

Der Fehler scheint aus dem Programm zu stammen (roter Kreis mit
wei�em Kreuz, Text SHARE FEHLER in ausschlie�lichen Gro�buchstaben,
kein typisches Win32-Fehlerfenster, aber auch nicht wie normale
Delphi-Execptions: die kommen dann sp�ter noch).

2. Wird in der Anwendung eine SELECT-Abfrage via TQuery verwendet?

nein; TSession,TDataSource,TTable

3. Wie wird im Programm die Session-Eigenschaft PrivateDir
konfiguriert?

�berhaupt nicht, d.h. bleibt auf Default aus der BDE, mu� ich das
denn? Die Tabellen die die Sharing-Probleme bereiten liegen zwar in
dem selben Verzeichnis hei�en aber unterschiedlich (Jede Anwendung
bekommt einen eindeutigen Tabellennamen zugeordnet). Wenn es sich
vermeiden l��t, m�chte ich auch nicht unbedingt weitere
Unterverzeichnisse anlegen m�ssen.
Habe versucht:
a) jeder Anwendung ein eigenes PrivatDir => hat nicht geholfen
b) die privaten Tabellen auch wirklich im PrivatDir abgelegt => hat
nicht geholfen.

4. Verschwindet die Fehlermeldung, wenn f�r die BDE die Eigenschaft
LOCAL SHARE aktiviert wird?

leider nein

5. Verwenden alle Clients tats�chlich einen gemeinsamen (identischen)
Wert f�r die BDE-Eigenschaft NET DIR?

Ja! Getestet mit NET DIR auf Server bzw. auch lokal.

6. Tauchen beim Zugriff auf gro�e Memo-Daten tempor�re Tabellen im
PrivateDir-Verzeichnis auf?
nein

Wenn ich die Stichw�rter Exclusiver Tabellenzugriff und Zugriff vom
lokalen Rechner aus h�re, f�llt mir spontan eine der
BDE-Performanceoptimierungen ein (Einsparen von Dateisperren). Werden
dann allerdings mehrere Programminstanzen auf dem gleichen Rechner
gestartet, die alle das gleiche PrivateDir verwenden, k�nne das
geschilderte Problem auftreten

**Andreas Kosch** · 20.10.1999, 11:24

Hallo,

sehr merkw�rdig - es scheint so, als ob zur Ursacheneingrenzung nur die Versuch+Irrtum-Methode am erfolgversprechensten ist. Es w�re auch interessant, an exakt welcher Stelle in der VCL der Fehler entsteht (Projekt mit Debug-Info incl. f�r die VCL-Sourcen compilieren):

1. Beseitigt das Erh�hen der Werte verschiedenen BDE-Parameter (siehe BDE-Verwaltung -> Konfiguration -> Sytem -> INIT) das Problem (MEMSIZE, SHAREDMEMSIZE, MAXFILEHANDLES)?

2. Was passiert, wenn die Tabellen nicht bereits in der IDE, sondern erst zur Laufzeit im Programm ge�ffnet werden. Tritt der Fehler auch dann immer noch auf, wenn keine Tabelle in der IDE beim Compilieren aktiv ist (nicht nur die temp./benutzerbezogenen)?

3. Wann werden die Tabellen mit Exclusiv-Rechten ge�ffnet? Erst unmittelbar vor dem Aufruf von EmptyTable oder bereits von Anfang an via Objektinspektor? Verschwindet der Fehler, wenn Exclusiv erst zur Laufzeit aktiviert wird? Sind noch andere, feststehende Tabellen zu diesem Zeitpunkt exclusiv ge�ffnet?

4. Um ein NT-Problem auszuschliessen, kann der folgende Versuch gemacht werden: 
a) Das Programm �ffnet eine Test-Tabelle und schliesst diese wieder. 
b) Kann diese (geschlossene) Tabelle �ber den Explorer als Datei von Hand gel�scht werden, wenn die Anwendung noch l�uft?

5. Sollte alles nichts helfen, kann ich nur noch anbieten, einen Blick auf das vorbereitete Testprogramm zu werfen (eMail an [email protected]).
&#10

**Jens Hoyer** · 20.10.1999, 15:32

sehr merkw�rdig - es scheint so, als ob zur Ursacheneingrenzung nur
die Versuch+Irrtum-Methode am erfolgversprechensten ist. Es w�re auch
interessant, an exakt welcher Stelle in der VCL der Fehler entsteht
(Projekt mit Debug-Info incl. f�r die VCL-Sourcen compilieren):

Komt man leider auch nur bis zur Stelle dbiEmptyTable in der Unit
dbTables: liefert ErrorCode 11058=SHARE-Fehler

1. Beseitigt das Erh�hen der Werte verschiedenen BDE-Parameter (siehe
BDE-Verwaltung -> Konfiguration -> Sytem -> INIT) das Problem
(MEMSIZE, SHAREDMEMSIZE, MAXFILEHANDLES)?

Ich stehe, glaube ich, auch schon am oberen Limit MEMSIZE=16,
SHAREDMEMSIZE=4096, MAXFILEHANDLES=2048

2. Was passiert, wenn die Tabellen nicht bereits in der IDE, sondern
erst zur Laufzeit im Programm ge�ffnet werden. Tritt der Fehler auch
dann immer noch auf, wenn keine Tabelle in der IDE beim Compilieren
aktiv ist (nicht nur die temp./benutzerbezogenen)?

-die Tabellen werden erst zur Laufzeit erstellt und aktiviert;
ebenso die zugeh�rigen Objekte TSession,TDataSource und TTable
-die IDE ist gar nicht aktiv (2x EXE): => Fehler tritt auch auf

3. Wann werden die Tabellen mit Exclusiv-Rechten ge�ffnet? Erst
unmittelbar vor dem Aufruf von EmptyTable oder bereits von Anfang an
via Objektinspektor? Verschwindet der Fehler, wenn Exclusiv erst zur
Laufzeit aktiviert wird? Sind noch andere, feststehende Tabellen zu
diesem Zeitpunkt exclusiv ge�ffnet?

Die Tabellen werden zur Laufzeit exclusive erzeugt

4. Um ein NT-Problem auszuschliessen, kann der folgende Versuch
gemacht werden:
a) Das Programm �ffnet eine Test-Tabelle und schliesst diese wieder.
b) Kann diese (geschlossene) Tabelle �ber den Explorer als Datei von
Hand gel�scht werden, wenn die Anwendung noch l�uft?
Vollkommen problemlos! L��t sich l�schen, wieder erzeugen
usw...

5. Sollte alles nichts helfen, kann ich nur noch anbieten, einen Blick
auf das vorbereitete Testprogramm zu werfen .

Soeben getan. Und: DANKE.</b&gt

**Andreas Kosch** · 21.10.1999, 05:47

Hallo Jens,

ich werde erst heute Abend dazu kommen, die eMail auszulesen. Wenn der Fehler beim Aufruf von dbiEmptyTable kommt, w�rde ich doch noch einmal 2 Tests machen: 
1. MEMSIZE=64 (16..205 MB zul�ssig); SHAREDMEMSIZE=16384 (kByte) 
2. SHAREDMEMLOCATION: Adress-Wert �ndern (siehe BDE-Hilfe: Vorgabewert (f�r Windows NT): 0x6BDE0000; Kleinster Wert (f�r Windows NT): 0x10000000; Gr��ter Wert (f�r Windows NT): 0x7F000000

**Jens Hoyer** · 21.10.1999, 14:07

1. MEMSIZE=64 (16..205 MB zul�ssig); SHAREDMEMSIZE=16384 (kByte)

Hat beides nicht geholfen

2. SHAREDMEMLOCATION: Adress-Wert �ndern (siehe BDE-Hilfe: Vorgabewert
(f�r Windows NT): 0x6BDE0000; Kleinster Wert (f�r Windows NT):
0x10000000; Gr��ter Wert (f�r Windows NT): 0x7F000000 )

Habe mangels besseren Wissens einige Adressen durchprobiert: der
Fehler bleibt und manchmal kommt noch hinzu, da� die 2. Anwendung die
gemeinsam genutzten Tabellen �berhaupt nicht �ffnen kann</b&gt

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

Hallo,

ich habe mir das Testprogramm angeschaut und bin zu folgenden Ergebnissen gekommen: 
- 1. Programminstanz: Start mit C:\Ablage\TestCADdy2.exe 
- 2. Programminstanz: Start mit C:\Ablage\TestCADdy2.exe U 
- Beide Programme legen Datenbanktabelle auf E:\ an 
- Test mit 2000 Datens�tzen: Aufladen -> �bertragen -> Leeren -> keine Fehlermeldung 
- Test mit 6000 (erste Instanz) und 7000 (zweite Instanz) Datens�tzen: Aufladen -> �bertragen -> SHARE-Fehler bereits beim Aufladen (also kann es nicht die ISAPI-Funktion f�r das Leeren der Tabelle sein), nachdem die Anzeige der �bertragenen Datens�tze gleich dem Wert der aufgeladen Datens�tze ist. Die User DB der ersten Instanz kann geleert werden, die zweite Instanz jedoch nicht (SHARE Fehler). Der SHARE Fehler in der zweiten Instanz bleibt auch dann, wenn die erste Instanz geschlossen wird.

In den Funktionen Aufladen und �bertragen wird die private Methode WaitForLockTable(TableAllDBID,ltWriteLock) aufgerufen. Dort wird bis zu 500 Mal versucht, eine Tabellensperre zu setzten, wobei ich zus�tzlich �ber iCollisionCnt die Anzahl
der Kollisionen ermittle:
<pre>
procedure TForm1.WaitForLockTable(ATable: TTable; LockType: TLockType);
var i : integer;
begin
for i:=1 to 500 do begin
try
ATable.LockTable(LockType);
if i > 1 then
Inc(iCollisionCnt);
break;
except
Sleep(150);
if i=500 then raise; // Ende der Fahnenstange
end;
end;
end;
</pre>

Die TTable-Methode LockTable wird in der Unit DBTables �ber den Aufruf der IDAPI-Funktion DbiAcqTableLock implementiert. Und in der BDE.HLP steht zu dieser Funktion der folgende Satz: Redundant locks can be acquired on the table. For each lock acquired, a separate call to DbiRelTableLock is required to release it. In den BDE-Limits (siehe http://www.borland.com/devsupport/bde/ti_list/TI2751.html)
wird auf eine maximale Obergrenze f�r die Tabellensperren hingewiesen. Es sieht so aus, also ob f�r jeden Aufruf von LockTable ein UnlockTable-Aufruf notwendig ist.

Bei 2 x 7000 Datens�tze erhalte ich beim Aufladen 159 Kollisionen (beide Anwendungen liefern die gleiche Zahl zur�ck). Nach jedem Aufladen/�bertragen schliesse und �ffne ich dann die Tabellen (damit alle Sperren automatisch entfernt werden). Nun kann ich 7000 Datens�tze verarbeiten, ohne auf den SHARE-Fehler zu stossen!

Problem gel�st

**Jens Hoyer** · 22.10.1999, 15:29

Leider nein!

Da� beide Instanzen die gleiche Anzahl von Kollisionen liefern ist
normal und richtig, denn nur diese beiden Instanzen konkurrieren
miteinander, wobei ich aber 159 von 7000, also nicht einmal 3%, f�r
eine vertr�gliche Gr��e halte.

Ein nicht gelungenes LockTable kann leider nicht durch ein UnlockTable
repariert werden:
Exception "Objekt nicht gesperrt"

Das Schlie�en der Tabellen (und damit verbundenes Abmelden des
Benutzers von der Datenbank) ist, denke ich f�r MultiUserSysteme nicht
tragbar, da genau in diesem Moment eine andere Instanz daher kommen
k�nnte und, da sie ja nun der einzige Benutzer der Tabelle ist,
DeleteTable ausf�hrt.

Ich bin durchaus auch der Meinung, da� am Locking irgendwas faul ist,
weil: befragt man die Table mit DbiIsTableLocked so liefert dies nur
True wenn meine eigene Instanz die Sperrung errichtet hat. Hat eine
andere Anwendung die Sperre errichtet, behauptet DbiIsTableLocked
eiskalt: die Table ist voll verf�gbar. Ich denke das ist nicht ganz
richtig so, und l�uft vielleicht auf den selben Bug hinaus, der noch
keinem aufgefallen sein sollte? Nee, ich denke daf�r ist die
Aufgabenstellung zu gew�hnlich.

Was die Obergrenzen der Sperrungen anbetrifft so sind mir diese voll
bewu�t, im Normalfall ist pro Instance immer nur eine Sperrung aktiv
und wird auch k�rzest m�glich wieder freigegeben. Und bisher spreche
ich hier von nur zwei Instanzen. Auch in dem Testprogramm h�tten sich
die Sperrungen nicht aufsummieren d�rfen.

Irgendwo l��t die BDE wohl noch weitere Informationen zum
Tabellenstatus. Eventuell hilft auch folgende Fehlerbeschreibung, die
auch mit Sperrungen zu tun hat. St�rzt eine BDE-Application ab oder
wird sie aus der IDE gewaltsam (Strg-F2) beendet, dann bleiben die
Tabellen irgendwie gesperrt. Das n�chste �ffnen liefert dann die
Exception "Tabelle ist in Benutzung durch ...". Hierbei gilt zu
bemerken, da� es sich um ganz normale BDE-Applicatiopnen handelt, d.h.
SingleUser, kein Locking usw. . Eine weiter Information, die ich noch
beisteuern kann, ist folgende. Wenn die Datenbanken auf einem Server
abgelegt werden und man dann beobachtet was in dem
DataSource-Verzeichnis so abl�uft, so staunt man nicht schlecht, wie
viele tempor�re Datenbanken die BDE dort benutzt.

Zu Ihrem Quelltext: So ganz verstehe ich nicht, was Sie mit dem
Counter machen. Sie z�hlen die Sperrungen, da NACH der ersten Sperrung
erfolgreich sind? Wozu?

Ich bin f�r jede weiter Idee zu meinem Problem dankbar..

**Andreas Kosch** · 23.10.1999, 08:00

Hallo,

auf was bezieht sich Ihre Anwort Leider nein!: Tritt bei Ihnen der Fehler trotzdem noch auf oder ist der Weg an sich ungeeignet?

Mein Counter iCollisionCnt z�hlt nur die nicht sofort erfolgeichen Lock-Anforderungen. Immer dann, wenn die Schleifenvariable gr��er 1 ist, ist mindestens ein LockTable-Aufruf fehlgeschlagen, so da� nach 150ms ein weiterer Versuch unternommen wird. In iCollisionCnt steht am Ende die Anzahl der Fehlversuche.

Was die Obergrenzen der Sperrungen anbetrifft so sind mir diese voll bewu�t, im Normalfall ist pro Instance immer nur eine Sperrung aktiv und wird auch k�rzest m�glich wieder freigegeben. Und bisher spreche ich hier von nur zwei Instanzen. Auch in dem Testprogramm h�tten sich die Sperrungen nicht aufsummieren d�rfen. 

Nein - das glaube ich nicht. Offensichtlich gilt die Obergrenze von 256 (??...aus meinem Ged�chtnis) Locks auch f�r Lockversuche auf diese Tabelle. Bereits nach dem Aufladen waren davon 159 Locks verbraucht. Wenn ein nicht gelungenes LockTable nicht durch ein UnlockTable repariert werden kann, bleibt wohl nichts anderes �brig, als die Tabellen kurzzeitig zu schliessen (denn dann lehrt die BDE implizit alle Lock-Puffer f�r diese Tabelle).

Da der Effekt nur dann auftritt, wenn zwei Programminstanzen auf dem gleichen Rechner ausgef�hrt werden, gehe ich davon aus, das die BDE intern in diesem Sonderfall eine "Optimierung" durchf�hrt, die leider diese Nebenwirkungen zeigt

**Jens Hoyer** · 23.10.1999, 11:45

"Leider Nein" bezieht sich auf Ihre letzte Frage, n�mlich ob das
Problem damit gel�st ist.

Und ich denke, da� es das nicht ist. Denn das Schlie�en und �ffnen der
Table ist zwar ein Workaround, aber eigentlich keine L�sung.

Zu Ihrem Counter:
Ich denke, da� Sie sich irren. Der Counter wird nur hochgez�hlt, wenn
der n. Versuch klappt, wobei n>1 sein mu�. Da immer beim Locken eine
exception auftritt wenn das Locken nicht ging, kommen Sie gar nicht in
den Genu�, z�hlen zu k�nnen, wie oft das Locken nicht ging. Der
Counter zeigt nur, wie oft das Locken erst ab dem zweiten Versuch
ging - nicht wie oft der einzelne Versuch wiederholt werden musste. Um
das zu Summieren h�tten Sie den Counter in den Except-Block eintragen
m�ssen. Sie haben nur gez�hlt, wieoft es ging wenn es vorher schonmal
nicht ging.

Glauben Sie mir? Dann sollten Sie jetzt weiterlesen:
Und als ich das jetzt gerade mit Zahlen belegen wollte und Ihnen
schreiben wollte, wie hoch der Counter z�hlt, wenn man die Exceptions
z�hlt, da habe ich (und ich bin Baff) festgestellt, da� beide Counter
(Ihrer und meiner im Except-Block) identische Werte zeigen!!!! Nicht
da� ich Ihrem Counter nicht traue, aber da� mein Counter um -1
versetzt identische Werte zeigt, �berrascht mich sehr. Denn ich z�hle
die Anzahl der Exceptions. Und wenn beide Werte gleich gro� sind
(fast) w�rde das hei�en, da� jeder zweite Versuch immer klappt.
Und daran glaube ich nun wirklich nicht.

Also ich bleibe da dran! Aber ich bin etws mutlos... Erstens habe ich
sicher keinen Einflu� auf die Reparatur dieses Sonderfalls eines
BDE-Einsatzes und zweitens brauche ich eine L�sung, und da werde ich
wohl vorerst verhindern, da� ein Anwender den gleichen Datenbestand
zweimal auf dem selben Rechner �ffnet.
Schade. W�re genial gewesen. Trotzdem: Ich werde am Wochenende noch
ein bi�chen daran drehen

**Andreas Kosch** · 23.10.1999, 12:25

Hallo,

so war meine Antwort Mein Counter iCollisionCnt z�hlt nur die nicht sofort erfolgeichen Lock-Anforderungen ja auch gemeint.
Das Ihr Counter um -1 niedrigere Werte zeigt, �berrascht mich nicht. Es ist doch egal, ob oberhalb des Aufrufs von ATable.LockTable(LockType); (die Z�hlung vor dem Aufruf ber�cksichtigt dann auch die fehlgeschlagenen Versuche) gez�hlt wird oder darunter. Wenn die Sperre gesetzt werden kann, mu� mein Counter automatisch einen Wert h�her sein als der im Exception-Block (denn der letzte Versuch ist ja erfolgreich gewesen, so da� keine Exception ausgel�st wird).

Falls ein Anwender mehrere Programminstanzen auf dem gleichen Rechner starten soll, w�rde ich folgendes machen: 
1. Pr�fen, ob bereits eine Programminstanz l�uft. 
2. Wenn ja, einen Win32-Semaphore (oder MUTEX) anfordern und den Zugriff auf die Tabelle so synchronisieren. Somit m�ssen die lokalen Tabellen nicht mehr �ber die BDE gesperrt werden, so da� auch keine Locks hochlaufen k�nnen.

P.S. Das so h�ufige Sperren kompletter Tabellen ist nicht der Normalfall - auch in einer Mehrbenutzerumgebung werden meistens nur die Datens�tze gesperrt

**Andreas Kosch** · 25.10.1999, 06:14

Hallo Jens,

ich habe einige zus�tzliche Versuche gemacht, wobei sich allerdings meine erste Vermutung (die BDE sperrt in diesem Sonderfall nach dem Wechselschalterprinzip) leider nicht best�tigt hat. Hier meine neuen Zahlen:
<pre>
procedure TForm1.WaitForLockTable(ATable: TTable; LockType: TLockType);
var i : integer;
begin
for i:=1 to 500 do begin
try
Inc(iCallCnt);
ATable.LockTable(LockType);
if i > 1 then
Inc(iCollisionCnt);
break;
except
Inc(iExceptionCnt);
if bSecondUser then
Sleep(175)
else
Sleep(150);
if i=500 then raise; // Ende der Fahnenstange
end;
end;
end;
</pre>

<table border="0">
<tr>
<td>Anzahl der Datens�tze</td>
<td>iCollisionCnt </td>
<td>iExceptionCnt </td>
<td>iCallCnt </td>
<td>SHARE-Fehler </td>
</tr>
<tr>
<td>Aufladen von 2000 (1. Instanz) </td>
<td>42</td>
<td>82</td>
<td>2082</td>
<td>Nein</td>
</tr>
<tr>
<td>Aufladen von 2000 (2. Instanz)</td>
<td>42</td>
<td>99</td>
<td>2099</td>
<td>Nein</td>
</tr>
<tr>
<td>�bertragen von 2000 (1. Instanz) </td>
<td>36</td>
<td>92</td>
<td>2092</td>
<td>Nein</td>
</tr>
<tr>
<td>�bertragen von 2000 (2. Instanz) </td>
<td>37</td>
<td>107</td>
<td>2107</td>
<td>Nein</td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Aufladen von 7000 (1. Instanz)</td>
<td>43</td>
<td>169</td>
<td>7169</td>
<td>Nein</td>
</tr>
<tr>
<td>Aufladen von 7000 (2. Instanz)</td>
<td>42</td>
<td>167</td>
<td>7167</td>
<td>Nein</td>
</tr>
<tr>
<td>�bertragen von 7000 (1. Instanz)</td>
<td>77</td>
<td>239</td>
<td>7239</td>
<td>Ja</td>
</tr>
<tr>
<td>�bertragen von 7000 (2. Instanz)</td>
<td>77</td>
<td>252</td>
<td>7252</td>
<td>Nein</td>
</tr>
<tr>
<td>(Tabellen werden gel�sch, 
zweite Instanz verwenden einen 
anderen Wert f�r Sleep)</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>Aufladen von 2000 (1. Instanz) </td>
<td>20</td>
<td>47</td>
<td>2047</td>
<td>Nein</td>
</tr>
<tr>
<td>Aufladen von 2000 (2. Instanz) </td>
<td>19</td>
<td>56</td>
<td>2056</td>
<td>Nein</td>
</tr>
</table&gt

**Jens Hoyer** · 26.10.1999, 08:07

Hallo Herr Kosch,

fehlt mir da jetzt was bei der Tabelle?? Oder verstehe ich nur nicht,
was Sie mir damit sagen wollen.

Unabh�ngig davon habe ich das sofort probiert und den Sleep zwischen
10 und 250 zuf�llig ermitteln lassen. Jetzt habe ich zwar nur bei
einer Instanz den Share-Fehler, aber was hei�t das...??

**Andreas Kosch** · 26.10.1999, 08:26

Hallo Jens,

�h - da war ich wohl bei meiner Argumentation zu schreibfaul gewesen. Was ich sage wollte ist das: Zuerst dachte ich, das die BDE in diesem Sonderfall (2 Instanzen auf dem gleichen Rechner, nur Zugriff auf lokale Tabellen) intern ein Win32-Sperrobjekt verwendet, und beiden Instanzen abwechselnd den Zugriff auf die Tabelle einr�umt. Allerdings m�ssten dann die Zahlen f�r iCollisionCnt und iExceptionCnt symetrisch in Beziehung stehen - was aber leider nicht der Fall ist. Mit wachsender Tabellengr��e wird das Verh�ltnis schlechter. Auch das Variieren der Sleep-Zeit kann nicht zur Erkl�rung dieses Effekts (SHARE Fehler) beitragen.

Somit gehe ich davon aus, das in diesem Sonderfall eine Anomalie (um nicht Bug zu sagen) der BDE vorliegt. Man mu� also als Workaround entweder 
a) die Tabellen kurzeitig schlie�en, oder 
b) intern im Programm verhindern, das sich 2 lokale Instanzen in die Query kommen (Stichwort Win32-Sperrobjekte).
&#10

Announcement

SHARE FEHLER

SHARE FEHLER

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment