Batchmove mit sybase und Centura

[Frank Schneider]

Hallo Herr Kosch, bin mir nicht mehr ganz sicher, meine aber in einem Ihrer Bücher gelesen zu haben,
das Sie sich auch mit Centura - Datenbanken beschäftigen. In dieser Richtung habe ich zwei Fragen.
Ich selbst habe keine Erfahrung in der Administration von Centura, kenne mich nur mit der Sybase SQL - Anywhere
einigermassen aus.

Mein Ziel:
Ich möchte mittels Batchmove einen Datenbankabgleich von einer Sybase SQL Anywhere (5.5) zu einer
Centura SQL Base - Datenbank vornehmen.
Die zwei Tabellen, die ich sychronisieren will sind mit DataPump von der Sybase auf die Centura kopiert worden.
Das hat soweit geklappt.

1. Problem : meiner Applikation habe ich nun zwei Database - Komponenten, 2 TTable und 1 Batchmove
Starte ich das Programm bekomme ich immer die Fehlermeldung : Zieltabelle muss indiziert sein.
Die Zieltabelle auf Centura hat aber schon einen Index bekommen und es sind auch 3 Schluesselfelder in der
Tabelle angelegt. Was muss ich auf der SQL Base - Seite tun, damit es mit den normalen TTable - Einstellungen
funktioniert ?.

2. Problem : Mir ist jetzt schon 2 mal passiert, das ich mit dem SQL-Explorer die Centura Datenbank derart beschädigt habe,
das Sie zerstört war und neu angelegt werden musste. Dabei habe ich nur die Verbindung etabliert und wollte dann
den Verzeichnisbaum Table expandieren - lange Zeit SQL - Sanduhr - Task "abgeschossen" da keine Rückmeldung, danach
Datenbankconnect zur Centura nicht mehr möglich. Der ODBC - Treiber ist allerdings mit dem Administrator - Konto eingerichtet.
Haben Sie eine Idee woran´s liegt und wie ich es verhindern kann ? . Ich habe allerdings den leisen Verdacht das vielleicht
Netzwerkprobleme daran schuld sind (Ethernet nach Token - Ring über Bridge)

Vielen Dank im voraus

[Andreas Kosch]

Hallo,

zu Problem 1: <br>
Ich kann das geschilderte Problem nicht nachvollziehen. Hier ist meine Testkonfiguration: <br>
1. Datapump hat die Paradox-Tabelle COUNTRY aus DBDEMOS in eine SQLBase 7.5.1-Datenbank kopiert. <br>
2. In der Paradox-Tabelle DBDEMOS.COUNTRY habe ich einen Datensatz geändert und einen neu hinzugefügt.<br>
3. In Delphi kommen 1 x TDatabase; 2 x TTable und 1 x TBatchMove auf ein Formular<br>
4. TDatabase verwendet einen ODBC-DSN (MERANT-Treiber 3.50.00.00) für die SQLBase-Datenbank<br>
5. "TableSource" verwendet die Tabelle COUNTRY aus DBDEMOS (Paradox) <br>
6. "TableTarget" verwendet die Tabelle COUNTRY aus der SQLBase-Datenbank <br>
7. Mit TBatchMove.Execute werden im Modus <b>batAppendUpdate</b> alle Änderungen fehlerfrei in die SQLBase-Datenbank übernommen.

Im Formualar verwende ich in diesem auf die Schnelle zusammengebastelten Beispiel die folgende Konfiguration:

<pre>
object Form1: TForm1
Left = 192
Top = 107
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 Button1: TButton
Left = 168
Top = 56
Width = 75
Height = 25
Caption = 'Button1'
TabOrder = 0
OnClick = Button1Click
end
object Database1: TDatabase
AliasName = 'ODBC_MUENSTER'
Connected = True
DatabaseName = '_SQLBase'
LoginPrompt = False
Params.Strings = (
'DATABASE NAME=MUENSTER'
'USER NAME=SYSADM'
'PASSWORD=sysadm')
SessionName = 'Default'
Left = 24
Top = 80
end
object TableTarget: TTable
DatabaseName = '_SQLBase'
TableName = 'COUNTRY'
Left = 64
Top = 80
object TableTargetNAME: TStringField
FieldName = 'NAME'
Size = 24
end
object TableTargetCAPITAL: TStringField
FieldName = 'CAPITAL'
Size = 24
end
object TableTargetCONTINENT: TStringField
FieldName = 'CONTINENT'
Size = 24
end
object TableTargetAREA: TFloatField
FieldName = 'AREA'
end
object TableTargetPOPULATION: TFloatField
FieldName = 'POPULATION'
end
end
object TableSource: TTable
Active = True
DatabaseName = 'DBDEMOS'
TableName = 'COUNTRY.DB'
Left = 64
Top = 16
end
object BatchMove1: TBatchMove
Destination = TableTarget
Mode = batAppendUpdate
Source = TableSource
Left = 112
Top = 48
end
end
</pre>
Eventuell ist der zusammengesetzte Primärschlüssel der "Übeltäter", aber das habe ich aus Zeitgründen nicht ausprobiert.

zu Problem 2: <br>
Den SQL-Builder verwende ich kaum, ich arbeite generell mit dem SQL-Explorer. Datenbankbeschädigungen hat es noch niemals gegeben

[Frank Schneider]

Hallo Herr Kosch,

Vielen Dank für Ihre prompte Antwort. Inzwischen habe ich mir die
Centura SqlBase 7.51 besorgt und weiter getestet. Das Problem liegt
ganz offensichtlich in der Datenbank begründet. Ich bin davon aus-
gegangen, das der ODBC - Treiber ein AutoCommit vornimmt - was er aber
anscheinend nicht tut. Wenn an der Centura mit SQL - Administrative
Änderungen an den Tabellen oder an der Datenbank vornimmt, keinen expliciten Commit - Befehl abschickt und geht dann mit dem SQL - Explorer auf die Centura los, kann sogar die Datenbank zerstört werden

[Andreas Kosch]

Hallo,

das glaube ich schon eher - nicht ohne Grund kann man im SQL-Explorer über "Optionen | Transaktion-Isolation" den Isolation Level definieren und dann über die Button eine Transaktion via COMMIT oder ROLLBACK definiert von Hand beenden

[Frank Schneider]

Herr Kosch - mein Batchmove funktioniert jetzt - zumindest meistens.
Ich habe die Tabellen mit Datapump kopiert und arbeite dann mit
Batappendupdate des Batchmove - funktioniert. Gehe ich jetzt hin und
lösche mit SQL - Talk den Inhalt der Ziel (Centura) Tabelle - abschließendes Commit - Statement und starte dann nochmal das Abgleichprogramm (Batchmove) habe ich einen endlosen SQL - Cursor ?.Schicke ich dann mittels SQL - Talk nochmals ein Commit - Statement ab fängt sich die Delphi-Anwendung und das Programm endet richtig. Werden die Datensätze nur aktualisiert gabs bisher noch keine Probleme. Ich benutze wie Sie den Merant-Treiber 3.50 - Standarteinstellun

[Andreas Kosch]

Hallo,

das sieht so aus, als ob Delphi beim Zugriff auf die Tabelle auf einen LOCK trifft und wartet - wobei der LOCK erst durch den nachfolgenden COMMIT-Aufruf in SQL Talk geseitigt wird. Was passiert, wenn die folgende Reihenfolge eingehalten wird:

1. <i>SQL Talk</i>: Datensätze löschen und über COMMIT bestätigen. <br>
2. <i>Delphi</i>: Datenbankverbindung (TDatabase) trennen und neu aktivieren. <br>
3. <i>Delphi</i>: Batchmove starten

Wenn das auch nicht funktioniert, gehe ich einmal davon aus, das sich die gleichzeitige Verbindung via SQL Talk (comdll=sqlws32) und dem ODBC-Treiber (der ebenfalls auf sqlws32 zugreift) auf dem gleichen Rechner in die Quere kommen. Was passiert, wenn in SQL Talk nach dem COMMIT ein DISCONNECT ALL aufgerufen wird, bzw. SQL Talk geschlossen wird, bevor BatchMove startet

[Frank Schneider]

Hallo, die Massnahmen die Sie vorschlagen habe ich ausprobiert - es scheint keine Rolle zu spielen ob man mit SQL - Talk connected ist oder nicht. Das problem scheint immer der append zu sein (bei zuvor geleerter Zieltabelle).
Meine Annahme das es vielleicht an der Centura liegt hat sich inzwischen auch fast zerschlagen. Ich habe die gleiche Versuchsreihe mit zwei Sybase - Datenbank gemacht - gleiches Verhalten. Auch hier bleibt mir die Applikation "hängen" wenn die Zieltabelle
leer ist - bis man mit sybase central einen Commit abschickt.
Der Verdacht drängt sich auf das es an Delphi 5 selbst liegt - ein Versuch auf einem anderen Rechner mit Delphi 4 (UpdatePack3)
gleiche Anwendung und 2 Sybase - Datenbank funktionierte unter allen Umständen. Der Versuch Sybase - Centura scheiterte dafür jedesmal. War auf der Zieltabelle kein Index vorhanden terminierte die Applikation mit "Zieltabelle muss indiziert sein".(O.K). Wenn
ich einen unique index auf der Centura erzeugt habe ( getestet mit voller und leerer Tabelle ) erhalte ich nach Abbruch "Tabelle besitzt keinen Primärindex". Ein Erstellen von Primary keys analog zum Index brachte auch nichts.

Ich tendiere langsam dazu die Sache per Sql-Queries zu lösen - ist zwar mehr Tipperei, scheint mir aber langsam erfolgsversprechender zu sein