Grupy dyskusyjne Google nie obsługują już nowych postów ani subskrypcji z Usenetu. Treści historyczne nadal będą dostępne.

Error[35]

0 wyświetleń
Przejdź do pierwszej nieodczytanej wiadomości

TS

nieprzeczytany,
15 paź 1999, 03:00:0015.10.1999
do
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

nieprzeczytany,
15 paź 1999, 03:00:0015.10.1999
do
wyglada na to, ze biblioteka nie jest zgodna z trybem chronionym.
Ale to moze byc równiez funkcja clippera

TS

nieprzeczytany,
15 paź 1999, 03:00:0015.10.1999
do

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

nieprzeczytany,
18 paź 1999, 03:00:0018.10.1999
do
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

nieprzeczytany,
18 paź 1999, 03:00:0018.10.1999
do

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

nieprzeczytany,
19 paź 1999, 03:00:0019.10.1999
do
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

nieprzeczytany,
19 paź 1999, 03:00:0019.10.1999
do
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

nieprzeczytany,
19 paź 1999, 03:00:0019.10.1999
do

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


Nowe wiadomości: 0