Pas på de globale variabler ved eksport og import

En godt skjult fejl vi ind imellem ser i Klassisk C5 (og XAL) er forkert brug af:

  • &OutFldDel: Udgående felt-separator (dvs. tegn mellem felter ved skrivning af eksportfiler)
  • &OutRecDel: Udgående record terminator (dvs. tegn i slutningen af linjen (recorden) ved skrivning af eksportfiler)
  • &InFldDel: Indgående felt-separator (dvs. tegn mellem felter ved læsning af eksportfiler)
  • &InRecDel: Indgående record terminator (dvs. tegn i slutningen af linjen (recorden) ved læsning af eksportfiler)

 

Med andre ord – hvis der skrives en fil med fx WRITE “<filnavn>” AS COMMA FROM… eller læses en fil med READ “<filnavn>” AS COMMA INTO… så benyttes disse variable til at definere hvilke tegn, der er hhv. mellem felterne og i slutningen af linjen.

 

Jamen hvordan kan de felter bruges forkert?

Jo – det mange overser er at felterne faktisk er globale variable og derfor IKKE returneres til deres defaultværdier når en kørsel afsluttes. Så har du en eksportkørsel A.xal der sætter &OutFldDel = ‘;’ og &OutRecDel = ‘<br>’, ja så overlever disse værdier når kørslen afsluttes. Så har du samtidigt en eksportkørsel B.xal der forventer at værdieren er standard (hhv. ‘,’ og ‘\r\n’), så afhænger dens resultat lige pludselig af om A.xal afvikles før (eller af om Klassisk C5 genstartes mellem A.xal og  B.xal køres).

 

Problemet kan naturligvis løses ved ALTID at sætte begge felter korrekt inden hhv. skrivning og læsning af filer – men du kan jo kun være herre over din egen kode – og er der fx indlæst moduler fra 3. part, ja så kan du komme ud for at din kode alligevel “ødelægger” noget hvis 3. part antager at felterne har nogle defaultværdier.

 

En bedre løsning er derfor følgende logik:

  1. Definer lokale variabler til at gemme værdierne og sæt disse lig variablernes værdi ved kørselsstart
  2. Sæt de globale variable som du ønsker det og kør din eksport-/import-kode
  3. Sæt de globale variable tilbage til de gemte værdier i de lokale variable i slutningen af kørslen

 

Hvis du indfører ovenstående som “best practice” i det du laver, så er du sikker på at dine kørsler ikke ødelægger andres antagelser om hvad felt- og record-separatorerne er – og du sikrer at selv andres dårlige eksport-kode afvikles korrekt.