Re: procedury *.w i *.p

[Henryk Jusza <henju@pg.gda.pl>]

>2) Ostatnio eksperymentowałem z instrukcj± BUFFER-COPY. Instrukcja jest
>wspaniała, ale jak zwykle nie do końca. Działała mi bardzo sprawnie w
>momencie przepisywania zawarto¶ci tablicy do bufora zadeklarowanego jako
>LIKE ta tablica. Jednak już w drug± stronę, czyli z bufora do tablicy,
>Progress meldował dziwne błędy. Oczywi¶cie nie były to błędy spowodowane
>NO-LOCK. W końcu zmuszony zostałem do użycie BUFFER-COPY tylko w jedn±
>stronę. Dziwne ?

Myślę, że jest tutaj błąd w rozumowaniu co sugeruje sformułowanie
‘przepisywanie zawartości tablicy do bufora’.  W programach PROGRESS’owych
występują bufory jawnie, deklarowane za pomocą deklaracji (a nie żadnej tam
‘instrukcji’ jak to podano w nazewnictwie PROGRESS’a)

  DEF BUFFER Nazwa_Bufora  FOR  Tablica

i bufory deklarowane niejawnie (predefiniowane automatycznie) dla każdej z
tablic o nazwie takiej samej jak nazwy tablic, których dotyczą. Przepisanie
informacji z tablicy z bazy do bufora jawnego czy też niejawnego wykonuje
się w momencie wykonania instrukcji FIND, FOR EACH w których podaje się
nazwę bufora (NIE tablicy !) który ma być zapełniony. Z kolei zapisanie
informacji z bufora do bazy następuje w momencie wykonania instrukcji
RELEASE (która również odnosi się do bufora a nie do tablicy) lub też
automatycznie w miejscu, gdzie kończy się zakres widzialności (scope)
bufora (np: na końcu pętli FOR, na końcu procedury). 

Instrukcja BUFFER-COPY, jak sama nazwa wskazuje, kopiuje z bufora do
bufora. Z tego co Pan pisze, ‘kopiowanie w drugą stronę, czyli z bufora do
tablicy’ sugeruje, że wykonywał Pan instrukcją:

  BUFFER-COPY Bufor_Jawny  TO Bufor_Niejawny

Inaczej mówiąc zaktualizował Pan dotychczasową zawartość Bufora_Niejawnego,
jeśli zawierał on jakiś zapis lub też jeśli Bufor_Niejawny nie zawierał
żadnego zapisu, to został utworzony (patrz w dokumentacji uwagi datyczące
instrukcji BUFFER-COPY) nowy zapis z teścią taką, jak zapis z
Bufora_Jawnego.  W miejscu gdzie kończył się zakres widzialności (scope)
Bufora_Niejawnego PROGRESS jego treść usiłował zapisać do bazy. W pierwszym
wypadku (aktualizacja) rzekome błędy mogły wynikać z zadziałania trigger’ów
utrzymujących integralność itp. W drugim przypadku, kiedy utworzył nowy
zapis, zapewne sygnalizował, że jego klucze nie są unikalne, bo tak
rzeczywiście jest, gdyż jest już jego pierwowzór w bazie (ten z
Bufora_Jawnego). Kopiowanie zazwyczaj wykonuje się bez kluczy unikalnych
(stąd opcje EXCEPT) lub też po skopiowaniu całości zmienia się je (stąd
opcje ASSIGN).  

Myślę, że Pana problem wynika z pewnego zamieszania terminologicznego firmy
PSC. W dokumentacji, w opisie frazy RECORD PHRASE, beztrosko pisze się, że
słowo ‘record’ jest nazwą tablicy lub bufora zadeklarowanego w DEF BUFFER.
Nie jest to prawda. Zawsze jest to nazwa bufora, tylko nie zawsze jawnie
deklarowanego. Kiedyś w dyskusji na naszej liście dość sporo i krytycznie
wypowiadałem się na temat opisu gramatyki języka PROGRESS 4GL. Myślę, że
ten przypadek potwierdza wysunięte wtedy tezy.

Jeśli chodzi o pierwszy problem, to trudno mi się wypowiadać, bo nie
korzystam z UIB (są alternatywne generatory programów), poza tym bez
zaglądania do programów *.w i *.p jest to dość ryzykowne. Mam pewne
pomysły, na wyjaśnienie tego, ale musiałbym je zweryfikować, a teraz jest
już piątek, godzina 16.30 i 30 stopni za oknem, więc może to zrobię w
poniedziałek (jak znajdę trochę czzasu).

Pozdrawiam 'listowiczów' !


                    
                     Henryk Jusza                          henju@pg.gda.pl
                     ---------------------------------------------------------
                     Ośrodek Informatyczny Politechniki Gdańskiej
                     Pracownia Rozwoju Oprogramowania
                     tel (058) 347-28-01          fax (058) 347-24-63
------
Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm
Obsluga listy:  listserv@zeto.bydgoszcz.pl
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
------