Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Error[35]

0 views
Skip to first unread message

TS

unread,
Oct 15, 1999, 3:00:00 AM10/15/99
to
Cześć

Chyba na ten temat już coś było, ale wtedy nie czytałem, bo nie używałem
exospace.
Program (Clipper 5.3 z bibliotekami NETLIB 6.5)zlinkowany przez Exospace
wysypuje się z komunikatem
Error[35]: General protection fault in "exename" at 0ADF:0172
..... load base=014F ......
Czasem szybszy jest:
Internal error 8002

Będe wdzięczny za pomoc

pozdrowienia
TS


M³yñski Dariusz

unread,
Oct 15, 1999, 3:00:00 AM10/15/99
to
wyglada na to, ze biblioteka nie jest zgodna z trybem chronionym.
Ale to moze byc równiez funkcja clippera

TS

unread,
Oct 15, 1999, 3:00:00 AM10/15/99
to

M³yñski Dariusz wrote:

wyglada na to, ze biblioteka nie jest zgodna z trybem chronionym.
Ale to moze byc równiez funkcja clippera

  Jeśli masz na myśli bibliotekê NETLIB to chyba s¹ zgodne skoro w przyk³adach znajduje siê wzorcowy plik linkowania dla exospace.

A tak dla uzupe³nienia:
program wysypuje siê w ró¿nych miejscach (browse, get, itd.);
kiedyś s³ysza³em o problemach z szybkimi maszynami, mo¿e o to chodzi; ja odpalam to na Celeronie 400.

Marek Horodyski

unread,
Oct 18, 1999, 3:00:00 AM10/18/99
to
Blad 8002 chyba znasz, musisz ustawic programem Optedit parametr ExtraMin w
swoim EXECU na wieksza wartosc. Sprawdzaj to za pomoca Memory( 0) i
emory( 2). Niekiedy potrzebne jest ustawienie go nawet na 32Mb, a bywa ze i
64Mb. Jak to nie pomoze, i nadal bedziesz mial GPF'a [Error 35] przejrzyj
zasoby Oazis - widzialem tam gdzies sposob namiaru funkcji, ktora powoduje
blad trybu chronionego - i nalezy ja albo poprawic, albo zastosowac inna.
Marek Horodyski

TS

unread,
Oct 18, 1999, 3:00:00 AM10/18/99
to

Jarek Pawlak wrote:

> W naszych aplikacjach ( 5.3 ) blad ten wystepowal jezeli w kluczu indeksowym
> uzywalismy funkcji descend() ale nie wiem czy to tlumaczy Twoj przypadek
> Rozwiazaniem jest przejscie na klauzule Descending

Dzieki.
Sprawdze to, ale jesli tak jest to mam sporo pracy, bo uzywam Descend() w
conajmniej 30 indeksach i na dodatek nie na calym kluczu indeksowym, a tylko na
czesci (np.: nazwisko+Descend(...).
Dlatego mam dwa pytania:
1.czy blad wystepowal przy poruszaniu sie po bazie z takim indeksem, czy
wystarczylo otwarcie takiej bazy z indeksami ?
2.czy przy szukaniu w indeksie z klauzula descend stosuje sie juz normalnie
funkcje Descend() tzn seek Descend(...), czy tez inaczej ?

pozdrawiam
TS


Jarek Pawlak

unread,
Oct 19, 1999, 3:00:00 AM10/19/99
to
Faktycznie, funkcja "descend" na czesci klucza to problem. Wg naszych
obserwacji blad ten wystepowal raczej przy zapisie do takiej bazy i przy
indeksowaniu.
Rozwiazaniem jest napisanie wlasnej funcji "MyDescend", ktora bedzie
zamieniac znaki na inne kody ASCII i umiescic ja w kluczu indeksowym.

W przypadku klauzuli descending szukasz normalnie po kluczu pierwotnym

Powodzenia

Ryszard Glab

unread,
Oct 19, 1999, 3:00:00 AM10/19/99
to
Jarek Pawlak wrote:
>
> W naszych aplikacjach ( 5.3 ) blad ten wystepowal jezeli w kluczu indeksowym
> uzywalismy funkcji descend() ale nie wiem czy to tlumaczy Twoj przypadek
> Rozwiazaniem jest przejscie na klauzule Descending


Zgadza sie. Funkcja Descend w Clipperze pracuje blednie. Jest
zamiennik FT_DESCEND w bibliotece Nanfor dostepnej ze zrodlami na Oasis.

Pozdrawiam, Ryszard

TS

unread,
Oct 19, 1999, 3:00:00 AM10/19/99
to

Jarek Pawlak wrote:

Usunalem wszystkie wywolania funkcji Descend(), ale niestety nie pozbylem
sie bledu.
Tak wiec u mnie przyczyna lezy gdzie indziej. Jeszcze z tym powalcze. Jak do
czego dojde to napisze.

Dzieki za wskazowki
Pozdrowienia
TS


0 new messages