Database - 17.07 - Problems

[TimStone]

James,

Sorry but I just don't have the time to do that right now. Norberto tried that code and it failed. I would likely have the same result. So far this problem has cost me 3 weeks ... and my clients are not happy.

Tim

[Diego Decandia]

Mr. Rao,

Unfortunately, I too have the same error as before, if I modify the Close method and keep the destructor...

[James Bott]

Diego,

Please check your code for closing a database object, then calling it after. I think this is the problem. Before when you closed an object it still existed, now it is destroyed. So, before it didn't necessarily cause an error, but now it does.

As I mentioned in a previous message, you can place a oDBF:=nil after each close method, one at a time, to find which one is causing the error. You have to do this using TDatabase 17.06 or earlier.

James

[Diego Decandia]

James,

I do not understand well... if I use Tdatabase 17:06 or earlier, there is no destructor and there has never occurred an error...

[James Bott]

Diego,

If you study the code in this link:

http://forums.fivetechsupport.com/viewt ... 45#p205269

You will see the kinds of things that can happen with ver 17.06 and earlier. They may not trigger error messages, but there are things happening that shouldn't be. Because of this I do believe you have some code in your program that is incorrect and this is what is causing the error in 17.07. It may be that your program is still working fine, but new code you write might not be working and may not show an error.

So, you have two choices, never upgrade to current FWH code, or change your app code to prevent errors with the new TDatabase class.

The same things will happen whether you are using TData or TDatabase.

Questions?

James

[Diego Decandia]

James and all,
using FWH 17.04 with TDatabase 17.04, new Close method, closing a database object, then calling it after, several times, no error.

[James Bott]

Diego,

>using FWH 17.04 with TDatabase 17.04, new Close method, closing a database object, then calling it after, several times, no error.

I'm not sure I understand what you mean.

Are you saying that you edited ver 17.04 TDatabase.prg and replaced the Close() method with the one from TDatabase 17.07?

Also, remember that no error doesn't mean that something hasn't gone wrong.

Note that if you are using TData then it overrides the Close() method of TDatabase.

James

[Diego Decandia]

Are you saying that you edited ver 17.04 TDatabase.prg and replaced the Close() method with the one from TDatabase 17.07?

Yes.

Also, remember that no error doesn't mean that something hasn't gone wrong.

Note that if you are using TData then it overrides the Close() method of TDatabase.
James

I used TDatabase 17.04 with new Close method

[James Bott]

Diego,

I have added more comments and messages to the sample code Nages provided. Perhaps this will make things more clear.

Code: Select all

   oStates  := TDatabase():New(nil, cStatesFile)
   oStates:use()
   ? oStates:Used(), oStates:FieldGet( 1 ) // --> .T., "WA"
   // do some work and close the object
   oStates:Close()  // dbf is closed but the object is still there
   //oStates:=nil     // Adding this solves the problem.
   //oStates:GoTop() // errors out, any version  

   msgInfo(oStates:nArea,"oStates:nArea")   // 1
   msgINfo(oStates:used(),"oStates:used()") // .f.

   oCust    := TDataBase():Open( nil, cCustFile, "DBFCDX" )
   ? oCust:Used(), oCust:FieldGet( 1 ) // --> .T., "Homer" // this is OK
   
   msgInfo(oCust:nArea,"oCust:nArea") // Returns 1

   oStates:GoTop()  // oStates is now using the workarea of oCust. No error.
   // This is wrong
   ? oStates:Used(), oStates:FieldGet( 1 ) // --> .T., "Homer"  // This is from the oCust database
   oStates:Close()  // Problem: This closes oCust

   ? oCust:Used() // --> .F., though we did not call oCust:Close()
   msgInfo(oStates:used(),"oStates:used()") // returns false since oCust is closed

Note that just because you don't get an error message doesn't mean that something isn't wrong. For instance you may be getting data from a different database object. This kind of thing is very hard to find.

Closing the object doesn't destroy it and we need to destroy it to prevent these kinds of issues.

James

[Diego Decandia]

James,

I am trying only my test, which first opens a dialog with a single TDatabase object, closes it, opens a dialog with a dbf, then closes it.
Trying several times, even at random, no error.

Using MsgInfo msgInfo(oStates:nArea,"oStates:nArea"), adapted to my test, after closing the database (oDB:End()) I get zero.

[James Bott]

Diego,

Like I showed in my code above, you don't have to get an error for things to be going wrong. Did you look at the code? Notice that oSales is showing data from oCust under those circumstances--and there are no errors.

Just using the new Close method from 17.07 isn't going to solve these kinds of problems. You have to destroy the object.

James

[James Bott]

Diego,

Try this simple test. Compile it with ver 17.06 or before. You will see that oStates is showing a field from oCust. And there are no errors.

Then uncomment this line:

oStates:=nil

And now there will be an error. This is why we need to destroy the object.

James

Code: Select all

/*
Purpose  : Very simple test showing how not destroying a database object
           can cause bad things to happen.
Program  : 
Author   : James Bott, jbott@compuserve.com
Date     :  09/06/2017 11:04:49 AM
Language : Fivewin/xHarbour
Updated  : 
Notes    :

*/

#include "fivewin.ch"

REQUEST DBFCDX

function Main()

   local oStates, oCust
   local cStatesFile:="c:\fwh\samples\states.dbf"
   local cCustFile:="c:\fwh\samples\customer.dbf"

   rddsetdefault( "DBFCDX" )
   memory(-1)

   oStates  := TDatabase():New(nil, cStatesFile)
   oStates:use()
   
   MsgInfo( oStates:FieldGet(1),"oStates:FieldGet(1)")  // "WA"
   
   oStates:Close()  // dbf is closed but the object is still there
   //oStates:=nil     // Adding this destroys the object
   //oStates:GoTop() // errors out, any version  

   oCust := TDataBase():New( nil, cCustFile, "DBFCDX" )
   oCust:use()
   
   msgInfo(oCust:FieldGet( 1 ),"oCustFieldGet(1)" ) // "Homer" // this is OK
   
   oStates:GoTop()  // oStates is now using the workarea of oCust. No error.

   // This is wrong
   msgInfo(oStates:FieldGet(1),"oStates:FieldGet(1)") // "Homer" Wrong

   oStates:Close()  // Problem: This closes oCust

   oCust:Close()

return nil

// EOF

[Diego Decandia]

James,

I'm sorry but at the line
>> oStates:GoTop() // oStates is now using the workarea of oCust. No error.

I get an error DBCMD/2001 Workarea non in use: DBGOTOP

I'm using TDatabase 17.04 with old Close Method

[James Bott]

Diego,

Well, I am using FWH 16.02 so there must have been some changes to your version. Here is the Close() method of 16.02:

Code: Select all

   METHOD Close()             INLINE ( ::nArea )->( DbCloseArea() ), If( ::oCn == nil,,::oCn:Close() ) // FWH 13.03

And in much earlier versions it was just:

Code: Select all

METHOD Close()             INLINE ( ::nArea )->( DbCloseArea() )
 

Sill all objects should be destroyed when you are done with them. So, the easiest way is to build it into the class as Nages has done in 17.07. Otherwise, you have to remember to set them to nil each time you End() them (or in the case of TDatabase, Close() them). Note that now in TDatabase 17.07, you can use End() instead of Close(). Using End() is consistent with how you end all other objects.

James

[James Bott]

Diego,

I just looked at the Close() method in TDatabase ver 17.06 and it is the same as in ver 16.02 so I am at a loss as to why you would get an error here when I don't. Unless your 17.04 version is different than 17.06?

Perhaps you had uncommented the oStates:=nil line, then got an error?

James