dbskipper intermitent error

[hag]

James It looks like Richard getting same error at msgwait(). See his first post.
Odd that we both get the dbskipper error at the same place.
Lets see if he confirms this.

[hag]

James
It looks like he may have the error at msgwait() also. Strange.

[Richard Chidiak]

James,

I did a research in those functions , none of them closes the database, this database is always open

As per changing the workarea , my netopen function makes sure the database is opened in the same area in case of , this is why i tried to trapp

if select(calias) = 0
return nil
endif

Harvey , sorry i do not have a msgwait in this part of my app

Richard

[James Bott]

Richard,

>I did a research in those functions , none of them closes the database, this database is always open

Did you do a global search of all your code looking for places where databases are closed? It may be in another function called from one of those functions.

>As per changing the workarea , my netopen function makes sure the database is opened in the same area in case of , this is why i tried to trapp

I was referring to the workarea being changed by any called function (or any function called by one of those functions) not in the section of code shown.

James

[hag]

Jmaes:
130 prgs. Big job.

[James Bott]

Richard,

My apologies, I am trying to follow too many threads at once and I got confused. Please ignore my previous message about functions.

You are getting a "workarea not in use" error with dbskipper().

And here is your definition of bSkip:

oBrwAPP:bSeek := {|c| DbSeek( Upper( c ) ) }

Do you see anything wrong with the above line?

James

[James Bott]

Harvey,

>Jmaes:
>130 prgs. Big job.

You need Copernic Desktip Search. Its global searches are very fast and you can preview each find on the screen without opening an editor. I can seach my entire hard disk in about 2 seconds. Ironically, it takes slightly longer to search a directory since you have to specify the directory.

It took me about 5 seconds to search all of the FWH source for "msgWait."

James

[James Bott]

Harvey,

After reviewing your error report again, I think you have the same problem as Richard.

Take a look at my previous message to him.

Richard and Harvey: I'll give you a hint. If you were using database objects you would never have these obscure, intermitant, and hard to find errors.

James

[hag]

I understand you comments but 130 prgs is a nightmare.

[James Bott]

Harvey,

>I understand your comments but 130 prgs is a nightmare.

Well, I don't disagree. However, I have recently been working on an application that I didn't write that is 104 PRGs, and Copernic has been extremely helpful. It would take me 10-100 times as long without Copernic. I highly recommend it (and I am not easily impressed).

Regards,
James

[nageswaragunupudi]

With due respects to one and all here, I can guarantee that this dbskipper error would NEVER occur, IF obrw:cAlias is explicity assigned and then oBrw;SetRDD is called, unless this alias is closed in some other code of the program.

Conditions:
1) oBrw:cAlias ---> SHOULD BE EXPLCITLY ASSIGNED. ( many programmers depend on the default behavior and it is dangerous )
2) Call oBrw:SetRDD() explicitly after assigning oBrw:cAlias
3) Make sure no other part of the program closes this alias by mistake while the browse is still being displayed.

If these three conditions are satisfied, this dbskipper should never occur ( unless the network gets disconnected momentarily or otherwise )

And, if we get this error, it means one of the above 3 conditions are not satisfied or if the dbf is referred from a networked computer, the network is inaccessible temporarily or otherwise.

[James Bott]

Richard,

Obviously, I need some sleep (I've been up all night).

>And here is your definition of bSkip:

>oBrwAPP:bSeek := {|c| DbSeek( Upper( c ) ) }

I misread the above line to be dbskip not dbseek(). Nevertheless this line still needs fixing. It may, or may not, be causing the dbskip error.

I suggest also doing as Rao suggests, calling setRDD() right after assigning the alias.

James

[Richard Chidiak]

James

Rao is right , i agree with the 3 points

After making further research , it looks like my file is closed somewhere in my app, it does not show on the active databases in the error.log

Nevertheless i am puzzled how we get to the error and why all the traps did not work, so i have some questions :

in setrdd() function , this line got executed

::bGoTop := {|| ( ::cAlias )->( DbGoTop() ) },;

while

::bSkip := {| n | iif( n == nil, n := 1, ), ( ::cAlias )->( DbSkipper( n ) ) },; bombed the error.log

the following trap did not work , again i am puzzled, why select(calias) did not return 0 when the file is closed ?

cAlias := ::cAlias
IF SELECT(cAlias) = 0
return nil
ENDIF

is there a way to make sure the database is active in the paint process ? in other words, can i put a real trap to exit

It is not easy to reproduce the error, occurs on some customers rarely, it is part of a mdi environment, i will make further research to check why and how the file was closed, meanwhile i am still looking for a trap to prevent the error.log

Thanks for your help

Richard

[hag]

Not sure but if this code is what you looking for. it will let you know if the databas is open.
It seems my app (Very large) closes out files i just reopen rather then spend hours looking for the close that happened.
Not great programing but it works.

Code: Select all  Expand view

function  IsAlias(cAlias)
   local lIsUsed := .f.

 
   if select(cAlias) > 0
      lIsUsed := .t.
   endif

   return lIsUsed
 

[James Bott]

Richard,

Logic would say that the dbgotop() worked because the database was still open when it was called.

Logic would also say that the if select( cAlias ) = 0 trap didn't work because the alias was still valid at that point. Possibly, it is a timing issue that a sysrefresh() or dbcommit() would solve. Or maybe, ::cAlias is nil and thus select( ::cAlias ) just returns the current workarea which is not zero.

Did you add the setRDD() to your code?

James