[Allegro] BCP primkey

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Liebe Liste,

der cstring "p" (oder primkey) liefert guenstigstenfalls (und vielleicht
irgendwann auch einmal zuverlaessig ;-) den Primaerschluessel des aktuellen
Datensatzes, damit sind aber einige Fallen verbunden, z.B. wenn man anhand
dieses Primaerschluessels den Satz in der Datenbank aufsuchen moechte.

Falle 1 ist in update.job bereits abgefangen:

var p   liefert einen String "|xSchluessel",
dabei x die Registernummer (1-9, ":", ";"). Fuer
die Formuluierung eines Suchbefehls benoetigt man
aber ein Spatium zwischen "|x" und dem Rest:

var p
ins #upk
var #upk(0,2) " " #upk(2,0)
find


Falle 2 gilt nicht fuer die Standard cat.api, wohl aber
fuer andere Anwendungen:

Wenn der Primaerschluessel gleichzeitig der/ein V14-Ersetzungs-
Schluessel ist, hat er die Form "Schluessel=|...". UPDATE.EXE
beruecksichtigt dies (der Neusatz zur gleichen Nummer koennte ja
eine geaenderte Ansetzung tragen), indem automatisch nur bis
zum "=" gesucht wird, und zwar trunkiert.

Um dieses Verhalten in einem Flex oder acon-Job nachzubauen,
benoetigt man folgende Konstruktion (die also noch ein
zusaetzliches if zur Vorbereitung enthaelt):

var p
ins #upk
if %=% var #upk(e"=") "=?";ins #upk
var #upk(0,2) " " #upk(2,0)
find


Falle 3 ist folgende (und wohl ein Problem von "find"):

Bevor ich Falle 2 bemerkte, stellte ich fest, dass das
Verfahren 1 (in update.job) manche Saetze nicht fand: Hier
ergab der Wert von "var p" einen String, der laenger als
die aktuell eingestellte Indexlaenge war und das darauf
basierende "find" scheiterte: Das laesst sich m.E. schwer
abstellen, denn eine vorauseilende Trunkierung der Suchbegriffe
durch find ist vermutlich kontraproduktiv: Die Umcodierung
der Benutzereingabe fuer das enstprechende Register koennte
ja durchaus scheinbar zu lange Suchbegriffe noch verkuerzen
oder aber scheinbar passende (durch Umcodierung etwa) kritisch
verlaengern. Eine sinnvolle Automatik muesste "tief unten"
ansetzen, also nach der Umcodierung durch die .cPI, hier koennte
ich mir vorstellen, dass urspruenglich untrunkierte Suchbegriffe
scheitern, wenn sie zu lang sind, urspruenglich trunkierte (also
mit angehaengtem "?" abgeschickte) jedoch heimlich auf die
Indexlaenge verkuerzt werden koennten. Darueber muss man aber
gewiss noch einmal nachdenken.

Ich finde uebrigens, dass das Trunkieren bei "=" nicht automatisch
bei der Bildung des cstring 'p' vorgenommen werden sollte: Die
derzeitige Loesung hat den Vorteil, dass ein realer Schluessel
zurueckgegeben wird, das ist nicht zu verachten.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSd4gEmITJZieluOzAQItvwQArsjUViNLyy2HRqlH/EPCwvz31+pUYArR
p8IsdRY4b9uWft/JWH+87STjVxBIMPjpUN7BM+d+TiCLrLXPAMAudyKcelyFUEEO
2XCVFNNcDTskn7b2lggz5y/nLi7VlzDVrbECrpo2HYNh5p3fTSSokm9itnSS1QZZ
U1e4xksXQvk=
=h+BE
-----END PGP SIGNATURE-----