Problem 3001

Zastrzegałem wcześniej, że o przełomie tysiąclecia nie będę pisał, czego posłusznie się trzymam. Tytuł felietonu sugerujący, jakobym chciał się zająć na wyrost już następnym tysiącleciem, aby konkurencję wyprzedzić, jest typową zmyłką - dla tych, którzy gazetę po tytułach jedynie wertują. W tym przypadku tajemnicza liczba dotyczy kodu błędu w najrealniejszej rzeczywistości eksploatacyjnej.

Zastrzegałem wcześniej, że o przełomie tysiąclecia nie będę pisał, czego posłusznie się trzymam. Tytuł felietonu sugerujący, jakobym chciał się zająć na wyrost już następnym tysiącleciem, aby konkurencję wyprzedzić, jest typową zmyłką - dla tych, którzy gazetę po tytułach jedynie wertują. W tym przypadku tajemnicza liczba dotyczy kodu błędu w najrealniejszej rzeczywistości eksploatacyjnej.

Tak bowiem objawia się niekiedy zapytanie funkcjonalne w środowisku MS Access 97 do bazy danych posadowionej na serwerze z systemem NetWare. Dla klarowności sytuacji chciałbym nadmienić, że zapytanie funkcjonalne to takie, które na zbiorze danych może wykonywać jedną z akcji SQL-a: delete, insert, update. W tym konkretnym przypadku program kliencki przeprowadzał działania na dosyć dużych tabelach umieszczonych na wydzielonym serwerze. Wzmiankowany kod 3001 Accessa objaśniany jest przez korporację następująco: "Nieprawidłowy argument. Nastąpiła próba wykonania operacji korzystającej z procedury DLL, dla której jeden z argumentów jest nieprawidłowy. Sprawdź wprowadzone polecenie, aby upewnić się, czy podany został właściwy argument, i powtórz operację".

Najciekawsze i jak dobrze znane z naszej informatycznej praktyki są dwa ostatnie słowa z cytowania. Powtarzałem więc i powtarzałem, jak informatyk wysiadający i wsiadający do samochodu, gdy ten nie chce się uruchomić. Tak to jest, gdy człowiek słucha głupich rad zamiast skoczyć po rozum do głowy. Po kilku próbach dałem spokój, uświadomiwszy sobie, że zapytania owe nie mają argumentów, których postać można by regulować.

Przeniosłem żywcem bazę danych na serwer NT, a tam wszystko hula, aż huczy. Wróciłem ponownie do NetWare, aby jednak przydybać go na błędach. W oprogramowaniu wykonałem poprawki, rezygnując z SQL-a, transakcje funkcjonalne zastępując stosownymi pętlami programowymi, z możliwością powtórzenia operacji w przypadku pojawienia się obsługiwanego programowo błędu 3001. Zaczęło działać, a ja przestałem obawiać się o utratę integralności danych. Po pewnym czasie pchany jakby przeczuciem zacząłem szperać po serwerze NetWare. I znalazłem: maximum record locks - taki parametr, mówiący, ile rekordów może być jednocześ-nie blokowanych. Okazał się zbyt mały, jak na wielkość bazy danych. Po jego zwiększeniu problem przestał istnieć.

Pracując na mainframe'ach, dostawałem białej gorączki, gdy brodząc po dokumentacji w poszukiwaniu rozwiązania, zamiast niego docierałem w końcu do magicznego stwierdzenia: "Skontaktuj się z programistą systemowym". Niezła rada, zważywszy że ja nim byłem. Myślę, iż enigmatyczne objaśnienia w dokumentacji technicznej powinny być zaopatrzone dodatkową klauzulą: "Jeśli posiadasz 20 lat praktyki i nie masz się z kim skonsultować, skorzystaj z intuicji. Na pewno znajdziesz poprawne rozwiązanie".

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200