Testing with dbfs, emptying them and generating them again i had the 
following problem

To improve the tests, i did a copy of the dbf in order that if i have to 
stop the program, then i restore the copy and begin again

to the original dbf it haven´t  field that is necessary for the index

So when i restore the dbf and i don't re-index, the program gives error !

then i can't close neither the index nor the dbf by any means

then i have a infinite loop of error that i can't finish, excep with alt + 
ctrl + sup

regards

If you have an index that uses a field that does not exist in the DBF,
what do you expect to happen??

But maybe I mess understand

Jim

On 04/13/2010 10:02 AM, Jorge L wrote:
> Testing with dbfs, emptying them and generating them again i had the
> following problem
> 
> To improve the tests, i did a copy of the dbf in order that if i have to
> stop the program, then i restore the copy and begin again
> 
> to the original dbf it haven´t  field that is necessary for the index
> 
> So when i restore the dbf and i don't re-index, the program gives error !
> 
> then i can't close neither the index nor the dbf by any means
> 
> then i have a infinite loop of error that i can't finish, excep with alt
> + ctrl + sup
> 
> regards
>

Hi james
sorry for my english
it is true that if the index have a key that the dbf not have, i have an 
error

but, when happend this, i can't close index, i can´t close database and i 
can´t execute dbcloseall()

i have this dbf in "PRV" alias, then
prv->( dbclearindex() ) giveme "", not NIL
prv->( dbclosearea() ) giveme "", not NIL
and dbcloseall() giveme "internal structure corupted" and i can´t close my 
aplication else alt+ctrl+del

i would wait that beyond the mistake, i should be able to close the files 
without another mistake

regards


"James Loughner" <jwrl@suddenlink.net> escribió en el mensaje de noticias 
news:5322c8f$6937a21f$5d874@news.alaska-software.com...
> If you have an index that uses a field that does not exist in the DBF,
> what do you expect to happen??
>
> But maybe I mess understand
>
> Jim
>
> On 04/13/2010 10:02 AM, Jorge L wrote:
>> Testing with dbfs, emptying them and generating them again i had the
>> following problem
>>
>> To improve the tests, i did a copy of the dbf in order that if i have to
>> stop the program, then i restore the copy and begin again
>>
>> to the original dbf it haven´t  field that is necessary for the index
>>
>> So when i restore the dbf and i don't re-index, the program gives error !
>>
>> then i can't close neither the index nor the dbf by any means
>>
>> then i have a infinite loop of error that i can't finish, excep with alt
>> + ctrl + sup
>>
>> regards
>>
>
>

hi,

> So when i restore the dbf and i don't re-index, the program gives error !

Your Index does not "match" any more to the DBF !

how are Index created ? what DBF (DBFNTX / FOXCDX) ?
Cl*pper or Xbase++ ?
DESCEND ?
FOR ?
any own DBESYS.PRG ?

Xbase++ does lock Index and "update" it every time you "move" in DBF.
it is also recommend to open "all" Index from a DBF and use OrdSetFocus()

greetings by OHR
Jimmy

Hi jimmy

 the dbf has 1 tag that i create with dbcdx with a for = !deleted() and 
without descend()

when i make the index, i have the record !

during my test.....,
i put a dbf that it hasn´t this field that i made the index

i know that ordcreate() lock the index file,

 but, this does that the dbf could not be closed by any means ?

"AUGE_OHR" <AUGE_OHR*AT*WEB.DE> escribió en el mensaje de noticias 
news:5dcecbc0$5792574c$5d83a@news.alaska-software.com...
> hi,
>
>> So when i restore the dbf and i don't re-index, the program gives error !
>
> Your Index does not "match" any more to the DBF !
>
> how are Index created ? what DBF (DBFNTX / FOXCDX) ?
> Cl*pper or Xbase++ ?
> DESCEND ?
> FOR ?
> any own DBESYS.PRG ?
>
> Xbase++ does lock Index and "update" it every time you "move" in DBF.
> it is also recommend to open "all" Index from a DBF and use OrdSetFocus()
>
> greetings by OHR
> Jimmy
>
>
>

hi,

> i know that ordcreate() lock the index file,
> but, this does that the dbf could not be closed by any means ?

to use ordcreate() you must have "lock" DBF exclusive or FLock()

use BEGIN SEQUENCE with BREAK / RECOVER if ordcreate() fail

greetings by OHR
Jimmy

Hi Jimmy
OK, i use begin sequence, etc. etc...,

when fail, i can´t close a database and i can´t quit of my program, except 
if i press alt + ctrl + sup

can´t quit of the program normaly, is it right ?

"AUGE_OHR" <AUGE_OHR*AT*WEB.DE> escribió en el mensaje de noticias 
news:71d60367$c1f0884$5d9a9@news.alaska-software.com...
> hi,
>
>> i know that ordcreate() lock the index file,
>> but, this does that the dbf could not be closed by any means ?
>
> to use ordcreate() you must have "lock" DBF exclusive or FLock()
>
> use BEGIN SEQUENCE with BREAK / RECOVER if ordcreate() fail
>
> greetings by OHR
> Jimmy
>
>

Look this is an error. You are doing this wrong and there is nothing to
do about it until you do it right. You can NOT just switch databases and
use the same index with incorrect fields.

If you switch databases build a new index with the proper fields.

Jim


On 04/14/2010 07:48 AM, Jorge L wrote:
> Hi Jimmy
> OK, i use begin sequence, etc. etc...,
> 
> when fail, i can´t close a database and i can´t quit of my program,
> except if i press alt + ctrl + sup
> 
> can´t quit of the program normaly, is it right ?
> 
> "AUGE_OHR" <AUGE_OHR*AT*WEB.DE> escribió en el mensaje de noticias
> news:71d60367$c1f0884$5d9a9@news.alaska-software.com...
>> hi,
>>
>>> i know that ordcreate() lock the index file,
>>> but, this does that the dbf could not be closed by any means ?
>>
>> to use ordcreate() you must have "lock" DBF exclusive or FLock()
>>
>> use BEGIN SEQUENCE with BREAK / RECOVER if ordcreate() fail
>>
>> greetings by OHR
>> Jimmy
>>
>>
> 
>

Jorge,

>So when i restore the dbf and i don't re-index, the program gives error !

That should be expected. It just seems that your program isn't reacting
correctly to the raised error.

>then i can't close neither the index nor the dbf by any means

I'm not sure what you mean by this. How do you know that you can't close
the databases or indexes? Are there additional errors? Do you get errors 
when accessing the files outside of your program?

>then i have a infinite loop of error that i can't finish, excep with alt + 
>ctrl + sup

This looks suspiciously like a programming fault. Unless you post your 
actual program, there is no way anyone can help you with this. It seems
quite obvious that you create that infinite loop yourself in your error
handling approach, though.

Whatever the problem is, you probably coded it that way.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Hi Andreas

I am going to use another example for this mistake

the point of this mail is when i perform dbcloseAll(), xbase giveme 
"structured corrupted"
from a mine mistake, i am thinking that i having discovered a mistake of 
xbase
well....
i use vxb2 and debug with it

look this case
i have opened a dbf in shared mode with the dbu.exe

when my program tries to open this dbf in exclusive mode (of course, xbase 
must not to open the dbf) sometimes dbcloseall() that i perform after the 
error give me "structure corrupted".

i stop the program before of dbcloseall() with altd(), and see all alias in 
use with the expression inspector
to all dbf that open without error dbclosearea() giveme nill and then 
select( narea ) give me 0
but
when i execute dbclosearea() to the dbf that i can´t open it beacouse i have 
it opened with dbu in shared mode, dbclosearea() giveme "" (not nil) and 
select( narea ) != 0, in my previous example, dbclearindex() give me "" too

the same thing happens if i put BEGIN SEQUENSE to the opening of the dbf...


thanks and regards

"Andreas Gehrs-Pahl" escribió en el mensaje de noticias 
news:a8tqf15e43nq.1bcecm4t7gala$.dlg@40tude.net...
> Jorge,
>
>>So when i restore the dbf and i don't re-index, the program gives error !
>
> That should be expected. It just seems that your program isn't reacting
> correctly to the raised error.
>
>>then i can't close neither the index nor the dbf by any means
>
> I'm not sure what you mean by this. How do you know that you can't close
> the databases or indexes? Are there additional errors? Do you get errors
> when accessing the files outside of your program?
>
>>then i have a infinite loop of error that i can't finish, excep with alt +
>>ctrl + sup
>
> This looks suspiciously like a programming fault. Unless you post your
> actual program, there is no way anyone can help you with this. It seems
> quite obvious that you create that infinite loop yourself in your error
> handling approach, though.
>
> Whatever the problem is, you probably coded it that way.
>
> -- Andreas
>
> ---                                                                      ---
>  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>  415 Gute Street                     or: Andreas@DDPSoftware.com
>  Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
>  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---
>

Hi again
i forgot to say you that in this example i don´t use indexes


"Jorge L" <jlborlando@way.com.ar> escribió en el mensaje de noticias 
news:2c33e25b$395dc209$80442@news.alaska-software.com...
> Hi Andreas
>
> I am going to use another example for this mistake
>
> the point of this mail is when i perform dbcloseAll(), xbase giveme 
> "structured corrupted"
> from a mine mistake, i am thinking that i having discovered a mistake of 
> xbase
> well....
> i use vxb2 and debug with it
>
> look this case
> i have opened a dbf in shared mode with the dbu.exe
>
> when my program tries to open this dbf in exclusive mode (of course, xbase 
> must not to open the dbf) sometimes dbcloseall() that i perform after the 
> error give me "structure corrupted".
>
> i stop the program before of dbcloseall() with altd(), and see all alias 
> in use with the expression inspector
> to all dbf that open without error dbclosearea() giveme nill and then 
> select( narea ) give me 0
> but
> when i execute dbclosearea() to the dbf that i can´t open it beacouse i 
> have it opened with dbu in shared mode, dbclosearea() giveme "" (not nil) 
> and select( narea ) != 0, in my previous example, dbclearindex() give me 
> "" too
>
> the same thing happens if i put BEGIN SEQUENSE to the opening of the 
> dbf...
>
>
> thanks and regards
>
> "Andreas Gehrs-Pahl" escribió en el mensaje de noticias 
> news:a8tqf15e43nq.1bcecm4t7gala$.dlg@40tude.net...
>> Jorge,
>>
>>>So when i restore the dbf and i don't re-index, the program gives error !
>>
>> That should be expected. It just seems that your program isn't reacting
>> correctly to the raised error.
>>
>>>then i can't close neither the index nor the dbf by any means
>>
>> I'm not sure what you mean by this. How do you know that you can't close
>> the databases or indexes? Are there additional errors? Do you get errors
>> when accessing the files outside of your program?
>>
>>>then i have a infinite loop of error that i can't finish, excep with alt 
>>>+
>>>ctrl + sup
>>
>> This looks suspiciously like a programming fault. Unless you post your
>> actual program, there is no way anyone can help you with this. It seems
>> quite obvious that you create that infinite loop yourself in your error
>> handling approach, though.
>>
>> Whatever the problem is, you probably coded it that way.
>>
>> -- Andreas
>>
>> ---                                                                       
>> ---
>>  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>>  415 Gute Street                     or: Andreas@DDPSoftware.com
>>  Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
>>  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
>> ---                                                                       
>> ---
>>
>
>
>

Hi Andreas, here i have a trace of appfatal, when mi errorsys execute 
dbcloseall()

SYS Thread-ID: 468
Module: EH
Error Codes: EH: 12 Sub: 0(0) OS: 0 XPP: 16
Call Stack of Thread 1 (468):
STANDARD_EH(417)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
skipping 1051 entries
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
_QUIT(9)
STANDARD_EH(515)
(B)ERRORSYS@0000(44)
ERRORLOG(387)
STANDARD_EH(553)
(B)ERRORSYS@0000(44)
ERRORLOG(387)
STANDARD_EH(553)
(B)ERRORSYS@0000(44)
ERRORLOG(387)
STANDARD_EH(553)
(B)ERRORSYS@0000(44)
ERRORLOG(387)
STANDARD_EH(553)
(B)ERRORSYS@0000(44)
ERRORLOG(387)
STANDARD_EH(553)
(B)ERRORSYS@0000(44)
ERRORLOG(387)
STANDARD_EH(553)
(B)ERRORSYS@0000(44)
ERRORLOG(387)
STANDARD_EH(553)
(B)ERRORSYS@0000(44)
MODUBICACCMD(804)
ALL0000(362)
MINIBROW(134)
CONSSTK(161)
(B)MENUA000@0000(67)
ABROWSE(70)
FACTUAA00(724)
VALAA00(475)
MENUAA00(218)
MENUA000(55)
MENU1000(38)
MENU0000(101)
DEPOSITO(372)
MAIN(92)
Call Stack of GUI Thread (656):
Call Stack of Thread 3 (1308):
DELARRAY(196)
**********************************************


"Andreas Gehrs-Pahl" escribió en el mensaje de noticias 
news:a8tqf15e43nq.1bcecm4t7gala$.dlg@40tude.net...
> Jorge,
>
>>So when i restore the dbf and i don't re-index, the program gives error !
>
> That should be expected. It just seems that your program isn't reacting
> correctly to the raised error.
>
>>then i can't close neither the index nor the dbf by any means
>
> I'm not sure what you mean by this. How do you know that you can't close
> the databases or indexes? Are there additional errors? Do you get errors
> when accessing the files outside of your program?
>
>>then i have a infinite loop of error that i can't finish, excep with alt +
>>ctrl + sup
>
> This looks suspiciously like a programming fault. Unless you post your
> actual program, there is no way anyone can help you with this. It seems
> quite obvious that you create that infinite loop yourself in your error
> handling approach, though.
>
> Whatever the problem is, you probably coded it that way.
>
> -- Andreas
>
> ---                                                                      ---
>  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>  415 Gute Street                     or: Andreas@DDPSoftware.com
>  Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
>  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---
>

Please Jorge

upload an simple and real sample.
(Dont forget the tables)

Regards
Osvaldo Ramirez

The example is not complex, only open a dbf exclusively in an application 
and to try to open it shared in other one, or vice versa
Of the index reject it, i understand that it generates confunción because i 
was trying to associate an index constructed for another dbf

But the point is that xbase loses the handle of the dbf, having or not 
mistake in the programming


Another thing that i did, was to do my own dbcloseall (), where i do a For 
from 1 to 300 and a dbclosearea () for every area, if it does not give me 
NIL i do a LOG, and... you do not know the surprise that was to discover all 
the times it happens

i trust that alaska reads this forum and that is a contribution to help that 
xbase improve




"Osvaldo Ramirez" <ramirezosvaldo@yahoo.com> escribió en el mensaje de 
noticias news:3d9e7df9$465b2a49$b13d6@news.alaska-software.com...
> Please Jorge
>
> upload an simple and real sample.
> (Dont forget the tables)
>
> Regards
> Osvaldo Ramirez
>

I do that all the time.

We need to see the way you are coding this. Are you doing a NetErr() to
make sure that the file opened?

Jim

On 04/20/2010 08:54 PM, Jorge L wrote:
> The example is not complex, only open a dbf exclusively in an
> application and to try to open it shared in other one, or vice versa
> Of the index reject it, i understand that it generates confunción
> because i was trying to associate an index constructed for another dbf
> 
> But the point is that xbase loses the handle of the dbf, having or not
> mistake in the programming
> 
> 
> Another thing that i did, was to do my own dbcloseall (), where i do a
> For from 1 to 300 and a dbclosearea () for every area, if it does not
> give me NIL i do a LOG, and... you do not know the surprise that was to
> discover all the times it happens
> 
> i trust that alaska reads this forum and that is a contribution to help
> that xbase improve
> 
> 
> 
> 
> "Osvaldo Ramirez" <ramirezosvaldo@yahoo.com> escribió en el mensaje de
> noticias news:3d9e7df9$465b2a49$b13d6@news.alaska-software.com...
>> Please Jorge
>>
>> upload an simple and real sample.
>> (Dont forget the tables)
>>
>> Regards
>> Osvaldo Ramirez
>>
> 
>

Hi

in my example i' am debbuging with a dbf opened in shared mode with the dbu 
(of clipper 5) compiled with xbase

in my program when open the dbf like this
      dbUseArea( .t., 'DBFCDX', M->DIR_DBF + 'ALARED', '_RA', .F. )
when my program execute this line, errorsys take a control, the last line of 
my errorsys is dbcloseall()
this does not happen always, only sometimes
the normal thing is that i could gather the mistake with NetErr()

regards


"James Loughner" <jwrl@suddenlink.net> escribió en el mensaje de noticias 
news:15795c2d$bb39564$b3b06@news.alaska-software.com...
>I do that all the time.
>
> We need to see the way you are coding this. Are you doing a NetErr() to
> make sure that the file opened?
>
> Jim
>
> On 04/20/2010 08:54 PM, Jorge L wrote:
>> The example is not complex, only open a dbf exclusively in an
>> application and to try to open it shared in other one, or vice versa
>> Of the index reject it, i understand that it generates confunción
>> because i was trying to associate an index constructed for another dbf
>>
>> But the point is that xbase loses the handle of the dbf, having or not
>> mistake in the programming
>>
>>
>> Another thing that i did, was to do my own dbcloseall (), where i do a
>> For from 1 to 300 and a dbclosearea () for every area, if it does not
>> give me NIL i do a LOG, and... you do not know the surprise that was to
>> discover all the times it happens
>>
>> i trust that alaska reads this forum and that is a contribution to help
>> that xbase improve
>>
>>
>>
>>
>> "Osvaldo Ramirez" <ramirezosvaldo@yahoo.com> escribió en el mensaje de
>> noticias news:3d9e7df9$465b2a49$b13d6@news.alaska-software.com...
>>> Please Jorge
>>>
>>> upload an simple and real sample.
>>> (Dont forget the tables)
>>>
>>> Regards
>>> Osvaldo Ramirez
>>>
>>
>>
>
>

Jorge,

>when my program execute this line, errorsys take a control, the last 
>line of my errorsys is dbcloseall()

Based on the little information that you have provided in the last nine
posts in this thread, I come to the following conclusions:

You use modified "ErrorSys()" and "ErrorLog()" routines, which result in 
a recursive error which leads to a fatal error due to stack exhaustion, 
which is shown in your "XppFatal.log".

If you would post the "ErrorSys()" routine -- or an example program that
shows the issue -- someone might be able to actually help you.

Posting baseless complaints about Xbase++ not working, won't do you any
good. In most of your posts you simply proclaim that there is a serious
error and ask if that is correct. I don't think I have seen a single
thread from you that started that way, which didn't ultimately resulted
in a programming error of yours being shown as the culprit.

It would help us (and you) enormously, if you could post a test program 
and a comprehensive problem description, when you start a thread, rather
then to reveal bits and pieces over a dozen posts, only to find out that
you had a minor programming error in your code.

I suggest that you encapsulate your "DbCloseAll()" in your "ErrorLog()"
(or "ErrorSys()") routine with a SEQUENCE, so that you don't get the
XppFatal error. Your "ErrorLog()" routine creates an error in line 387
and that started the recursive problem shown in the XppFatal.log that 
you posted earlier. After seven recursions, you program tries to quit 
the application and runs in another error -- in line 9 of your "_Quit()" 
routine -- which is probably another "DbCloseAll()" call.

But without your actual code, the above is just an educated guess on my
part, otherwise known as "pure speculation".

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Hi Andreas,

ROFLOL 

You will notice that I've not previously posted in this thread for 
exactly the reasons that you have stated below.

-Joe

Andreas Gehrs-Pahl wrote:
> Jorge,
> 
>> when my program execute this line, errorsys take a control, the last 
>> line of my errorsys is dbcloseall()
> 
> Based on the little information that you have provided in the last nine
> posts in this thread, I come to the following conclusions:
> 
> You use modified "ErrorSys()" and "ErrorLog()" routines, which result in 
> a recursive error which leads to a fatal error due to stack exhaustion, 
> which is shown in your "XppFatal.log".
> 
> If you would post the "ErrorSys()" routine -- or an example program that
> shows the issue -- someone might be able to actually help you.
> 
> Posting baseless complaints about Xbase++ not working, won't do you any
> good. In most of your posts you simply proclaim that there is a serious
> error and ask if that is correct. I don't think I have seen a single
> thread from you that started that way, which didn't ultimately resulted
> in a programming error of yours being shown as the culprit.
> 
> It would help us (and you) enormously, if you could post a test program 
> and a comprehensive problem description, when you start a thread, rather
> then to reveal bits and pieces over a dozen posts, only to find out that
> you had a minor programming error in your code.
> 
> I suggest that you encapsulate your "DbCloseAll()" in your "ErrorLog()"
> (or "ErrorSys()") routine with a SEQUENCE, so that you don't get the
> XppFatal error. Your "ErrorLog()" routine creates an error in line 387
> and that started the recursive problem shown in the XppFatal.log that 
> you posted earlier. After seven recursions, you program tries to quit 
> the application and runs in another error -- in line 9 of your "_Quit()" 
> routine -- which is probably another "DbCloseAll()" call.
> 
> But without your actual code, the above is just an educated guess on my
> part, otherwise known as "pure speculation".
> 
> -- Andreas
> 
> ---                                                                      ---
>   Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>   415 Gute Street                     or: Andreas@DDPSoftware.com
>   Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
>   Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---

hi,

>here i have a trace of appfatal, when mi errorsys execute
did you have a own ErrorSys.PRG ? show it !

when using BEGIN SEQUENCE, did you RECOVER your "old" Errorblock ?
what happend in line MODUBICACCMD(804) ?

> Another thing that i did, was to do my own dbcloseall (), where i do a For 
> from 1 to 300 and a dbclosearea () for every area, if it does not give me

look at c:\ALASKA\XPPW32\Source\SYS\AppExit.prg
it work with Workspacelist()

> NIL i do a LOG, and... you do not know the surprise that was to discover 
> all the times it happens
what LOG ? show it !

Question :
did you use SET RELATION ? you must "release" it before close !
did you use SET FILTER/SCOPE ? i do "clean" it before close ...
did you use Thread ? Workspacelist() is per Thread !
did you use a own DBESYS.PRG ? show it !

greetings by OHR
Jimmy