Het is onder BBx4 mogelijk om C-ISAM files te gebruiken. Men dient echter
zelf voor de run-time modules van Informix te zorgen.

Bij het openen van de bestanden moet worden aangegeven dat BBx met een
C-ISAM bestand aan de slag moet. Hiervoor dient elke open() te worden
uitgebreid met een MODE="CISAM". Indien dit achterwege wordt gelaten, kan
dit leiden tot een error 12, maar deze kan blijkbaar ook achterwege
blijven, waarna het bestand gewoon verziekt wordt.

De benadering van C-ISAM bestanden komt overeen met de benadering van
multikeyed MKEYED bestanden onder BBx. Dit betekent dat bij overgang naar
C-ISAM bestanden de BBx programma's moeten worden aangepast en dat een
aantal gebruikte methodes problemen kunnen geven. Het probleem is dat bij
het schrijven van een record niet langer de key mag worden opgegeven, omdat
de velden voor de sleutel uit het data deel worden gehaald.

Alle write() opdrachten zullen dus moeten worden aangepast. In sommige
gevallen wordt er een op lengte gebrachte key gebruikt met b.v. een masker
voor numerieke velden, terwijl in het datarecord de numerieke velden
zonder masker worden gebruikt. Dit kan bij C-ISAM files dus niet langer.
Het datarecord moet dan worden aangepast. Soms komt het voor dat de
sleutel niet (geheel) in het datarecord voorkomt, b.v. voor records met een
chronologisch volgnummer, waarbij het volgnummer alleen in de key is
opgenomen. Ook dit zal dan moeten worden aangepast.

In de "Additions and Corrections" worden nog een aantal C-ISAM afwijkingen
genoemd :

- Omgekeerde key volgorde wordt niet ondersteund door bestanden welke met
  C-ISAM zijn aangelegd
  *** wordt zelden of nooit gebruikt
- Als het eerste of laatste record door een andere gebruiker is verwijderd
  kunnen KEYF() en KEYL() verkeerd werken
  *** wordt zelden of nooit gebruikt
- FIND reset de filepointer wel, zodat errors 2 kunnen ontstaan bij verdere
  akties
  *** wordt weinig gebruikt
- TIM is niet beschikbaar als optie
  *** wordt waarschijnlijk nooit gebruikt
- Een geextract record wordt vrijgegeven bij de volgende READ, FIND of
  EXTRACT, voordat die aktie wordt uitgevoerd
  *** so what ?
- C-ISAM bestanden welke door INFORMIX4GL en ISQL zijn aangelegd krijgen
  niet noodzakelijk een primaire key. BBx verwacht een unieke primaire key,
  daarom gelden voor uitzonderingen de volgende regels :
  - READ loopt sequentieel door het bestand en slaat verwijderde records
    over
  - WRITE vervangt het geextracte record, als er geen record geextract is
    dat wordt het record over een voorheen verwijderd record heengeschreven
    of aan het einde van het bestand toegevoegd
  - Bij REMOVE moet i.v.m. de syntax KEY= worden gebruikt. Verder wordt
    niets met de key gedaan. KEY="" is dus geen probleem. Er wordt verwacht
    dat er een record geextract is en dit wordt verwijderd. Als er geen
    record geextract is, wordt er een error 17 afgegeven.
  *** alle bestanden hebben op de Pertec een unieke primaire key, dus dit
      is waarschijnlijk geen probleem
- Als via CISAM een single keyed bestand wordt aangelegd, dan wordt de
  recordlengte vergroot met de keylengte en wordt de key aan het einde van
  het bestand geplaatst. De flag ISNODUPS wordt gezet om aan te geven dat
  het bestand unieke primaire keys heeft.
  *** mogelijk heeft dit gevolgen voor het ALP en andere programma's welke
      records lezen en daarin gaan wroeten
- BBx kan niet overweg met variabele lengte C-ISAM files
  *** dat kon de Pertec ook niet
- C-ISAM file worden nooit gecached. Elk open kanaal verbruikt twee file
  handles en twee locks.
  *** Binnen DOS zijn zo'n 64 kanalen beschikbaar en daarvan worden er
      5 voor stdin, stdout, stderr, prn en com gebruikt. Er blijven er dan
      te weinig over voor b.v. een fakturering. Elk programma waarin UNT
      wordt gebruikt, vormt een mogelijk risico.
- Voor ERASE, OPEN en RENAME moet MODE=CISAM worden gebruikt.
  *** moet worden aangepast in de programmatuur, maar dat is met een search
      allemaal makkelijk op te sporen.
- Via SETOPTS kan op worden gegeven of BBx gecompileerd wordt met of zonder
  C-ISAM ondersteuning.
  *** Dit betekent waarschijnlijk dat alle programma's opnieuw gesaved
      moeten worden. Tegenwoordig wordt dit bijgehouden via byte 4 $01$.
      Vroeger werd byte 4 $10$ gebruikt om aan te geven dat C-ISAM
      bestanden werden ondersteund.
- Een C-ISAM file welke onder BBx is aangemaakt, is geen standaard file.
  Andere (niet INFORMIX) drivers kunnen mogelijk het bestand niet benaderen
  als het onder BBx is aangemaakt.
  *** hoe zit dit met Uniface ?


Terug naar het hoofdmenu...
Terug naar het BBx menu...
Alfabetische BBx inhoudsopgave...