Database - 17.07 - Problems

[Antonio Linares]

Diego,

Instead of calling MsgInfo() please use this code: x++

that will generate an error so we can review the calls stack, thanks

[Diego Decandia]

with x++ I get

>>>Error BASE/1003 Variabile inesistente: X
Errore avvenuto il 01/09/17, alle 18:54:58
PC: 'DIEGO-HP', Operatore: DIEGO
Tempo dallo start: 0 hours 0 mins 7 secs

Chiamato da: C:\fwh\source\classes\database.prg => TDATABASE:__DESTRUCTOR( 1360 )
Chiamato da: => TDATABASE:CLASSH( 0 )
Chiamato da: C:\Progs\Classi\TDATA.PRG => TDATA( 0 )
Chiamato da: C:\Progs\Classi\TXData.PRG => TXDATA( 0 )
Chiamato da: Funzioni.PRG => GTABCN( 344 )
Chiamato da: BuildMenu.Prg => (b)BUILDMENU( 104 )
Chiamato da: .\source\classes\MENU.PRG => TMENU:COMMAND( 1387 )
Chiamato da: .\source\classes\WINDOW.PRG => TWINDOW:COMMAND( 1081 )
Chiamato da: .\source\classes\MDIFRAME.PRG => TMDIFRAME:COMMAND( 262 )
Chiamato da: => TMDIFRAME:HANDLEEVENT( 0 )
Chiamato da: .\source\classes\WINDOW.PRG => _FWH( 3348 )
Chiamato da: => WINRUN( 0 )
Chiamato da: .\source\classes\WINDOW.PRG => TMDIFRAME:ACTIVATE( 1037 )
Chiamato da: MyShell.Prg => MYWNDMDI( 76 )
Chiamato da: Menu.PRG => MENU( 312 )

[Antonio Linares]

ok, thanks, in Class TDataBase remove this line:

// DESTRUCTOR td_destroy()

Also comment out this code:
/*
PROCEDURE td_destroy() CLASS TDataBase

::End()

RETURN
*/

[Diego Decandia]

Antonio,

Done. No errors.

ok, thanks, in Class TDataBase remove this line:

// DESTRUCTOR td_destroy()

Also comment out this code:
/*
PROCEDURE td_destroy() CLASS TDataBase

::End()

RETURN
*/

[norberto]

Antonio, no errors after proposal changes.

[nageswaragunupudi]

James,

Create a tData object for a database and put it in a browse.

Now, with double click, create a tRecord object. Do something with it. Save it and exit.

Go to another record on the browse. Create a tRecord object, do something. Save it and close it.

At this point, in my situation, when trying to save the value from the record, I received an error that suggests the database itself was closed.

How could this happen ? When opening the database itself, it might appear the records are stored in a memory cache. So we can move up and down a bit, but then when we try to SAVE() the tRecord, it wants to write to the database that is no longer open.

This is not happening with TDatabase.

I can not test with tdata/trecord. This is a sample for testing with TDataBase and TDataRow. TDataRow in fwh is what TRecord in tdata class. Difference is that TRecord works only with TData class but TDataRow works with any kind of datasource.

This sample may be tested:

Code: Select all  Expand view

#include "fivewin.ch"

REQUEST DBFCDX

function Main()

   local oStates, oDlg, oBrw

   oStates  := TDataBase():Open( nil, "c:\fwh\samples\states.dbf", "DBFCDX" )

   DEFINE DIALOG oDlg SIZE 400,600 PIXEL TRUEPIXEL
   @ 20,20 XBROWSE oBrw SIZE -20,-20 PIXEL OF oDlg ;
      DATASOURCE oStates AUTOCOLS CELL LINES NOBORDER ;
      ON DBLCLICK Edit( TDataRow():New( oStates ) )

   WITH OBJECT oBrw
      :CreateFromCode()
   END

   ACTIVATE DIALOG oDlg CENTERED

   oStates:Close()

return nil

function Edit( oRec )

   local oDlg

   DEFINE DIALOG oDlg SIZE 400,200 PIXEL TRUEPIXEL
   @ 20,20 SAY "Code" SIZE 60,20 PIXEL OF oDlg
   @ 50,20 SAY "Name" SIZE 60,20 PIXEL OF oDlg

   @ 20,100 GET oRec:Code SIZE 100,22 PIXEL OF oDlg
   @ 50,100 GET oRec:Name SIZE 250,22 PIXEL OF oDlg

   @ 90,20 BTNBMP PROMPT "SAVE" SIZE 150,30 PIXEL OF oDlg FLAT ACTION ( oRec:Save(), oDlg:End() )

   ACTIVATE DIALOG oDlg CENTERED

return nil
 

I am unable to see any problem with this. I can not comment if there is a problem with TRecord class.

[nageswaragunupudi]

I tested the code posted by Mr Diego Decandia on Aug 25th and seen the problem. It is also true we do not see the problem if we remove the DESTRUCTOR method td_Destroy(). But removal of this method is not the right solution.

This method did not create a new problem. In fact it brought to light that the present imlepemation of ::Close() method is UNSAFE. Surprisingly, it went unnoticed during all these years.

Let us do this small test using FWH 17.06 or any older version.

Code: Select all  Expand view

#include "fivewin.ch"

REQUEST DBFCDX

function Main()

   local oStates, oCust

   oStates  := TDataBase():Open( nil, "STATES", "DBFCDX" )
   ? 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

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

   oStates:GoTop()
   // This is wrong
   ? oStates:Used(), oStates:FieldGet( 1 ) // --> .T., "Homer"
   oStates:Close()  // Problem: This closes oCust

   ? oCust:Used() // --> .F., though we did not call oCust:Close()

return nil
 

So, we need to modify METHOD Close() not only in FWH 17.07 but in all earlier versions.
Fix:
For this line:

Code: Select all  Expand view

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

Substitute:

Code: Select all  Expand view

   METHOD Close()             INLINE If( Empty( ::nArea ) .or. Empty( ::cAlias ), nil, ;
                              ( ( ::nArea )->( DbCloseArea() ), ::nArea := 0, ::cAlias := "", If( ::oCn == nil,,::oCn:Close() ) ) )
 

After this modification, retaining td_Destroy(), the problem pointed out in the sample is resolved.

Fixed in 17.08

Some users may have a question in their minds. Is the DESTRUCTOR method td_Destroy() useful? Or is it reduntant or a hindrance? We will be discussing this in detail in the next posts.

[norberto]

Mr. Rao, i Try yor fix in fwh1707 database, dont work, Antonio proposed fix work fine.

thanks

[nageswaragunupudi]

Mr. Rao, i Try yor fix in fwh1707 database, dont work, Antonio proposed fix work fine.

thanks

Mr Norberto

There is no problem using TDatabase after the fix. I am unable to comment on why and how it is giving an error in TData, which is derived class. I do not know what methods are overridden and how they are handled in the derived class. Mr James only can help.

From my side, I undertake to provide error-free TDatabase and do whatever is necessary for it.

I shall be very much obliged if an error is shown using the base class, i.e., TDataBase, like a sample provided by Mr Mr Diego Decandia.

[norberto]

Mr Rao, thanks for your attention, i use tdata from james, until we discover an fix, i will use tdatabase from fwh17.05 or Antonio proposed coments in tdatabase 17.07.

very thanks

[James Bott]

Nages,

Good work discovering the situation where a database object is Closed or Ended and the object still exists. I have never come across this bug using TDatabase or TData but I can see that it could be an issue.

If I understand your new TD_Destroy method correctly, it is destroying the object whenever the Close() or End() method is called and this solves the problem. At least it appears to be in my testing.

I will make the appropriate changes to TData to accommodate the changes to TDatabase.

Thanks,
James

[nageswaragunupudi]

Mr James

Good work discovering the situation where a database object is Closed or Ended and the object still exists. I have never come across this bug using TDatabase or TData but I can see that it could be an issue.

Yes, this could be an issue, though very rarely. For many years we have been under the impression that the existing code is perfect till by accident we noticed it. This prompted me to review the existing code more carefully. I will cover this in my next post here. We are making the class a lot more safer in the next version.

If I understand your new TD_Destroy method correctly, it is destroying the object whenever the Close() or End() method is called and this solves the problem. At least it appears to be in my testing.

I shall be discussing in detail about DESTRUCTOR methods and how they work and what is the purpose and benefits of td_Destroy soon.
For now, let me say that a DESTRUCTOR method is called by (x)Harbour when all references to an object go out of scope. Kindly wait for my detailed discussion.

I will make the appropriate changes to TData to accommodate the changes to TDatabase.

Please wait a little. I will be sharing the version of 17.08 with you over email. Please let me know your email address.

[TimStone]

Nages,

I am fine with improving something. However, please consider:

+ tDatabase, tData, and tRecord have worked fine for many many years and not had a problem.
+ You made changes to tDatabase and we had major problems. Nothing else in our code, or tdata, or trecord changed.
+ I posted the problem about THREE WEEKS ago, and others stepped up to confirm it.
+ The problem was finally isolated, and a solution provided last week.

Now, you step in and say nothing is wrong with the changes you made, and that a program we have been using with FWH for about 10 years, without a single problem, must somehow be defective. I really have a hard time with that logic. tData is simply a class that inherits from tDatabase. It adds methods not covered in tDatabase, and a record methodology that works to protect our clients' data.

Yes, do make tDatabase safer, but please test it with COMPLEX data and code, to be sure it is accurate in the real world applications we build.

I have been going through my code to be sure it is very "tight" so nothing in there could cause any problems. However, it was working 100% correctly for my clients until the release of 17.07.

Tim

[James Bott]

Nages,

You can get my email address at my website which is shown on my profile.

I spoke too soon about reviewing and modifying TData to accommodate the new changes to TDatabase.

It was reported by one TData user that removing the ::end() call in the new TDatabase TD_Destroy procedure solved the problem. This would indicate that TData users having this problem will have to modify their code to solve the problem. It appears that they may be closing a database object and this now causes another object to use the wrong workarea. I expect they would have the same problem if they were using TDatabase instead of TData.

This also means that it is not possible to make a change in TData that would fix the problem since the TD_Destroy procedure in TDatabase cannot be overridden (nor would it be wise to do so).

James

[James Bott]

Tim,

Please run the code in this message:

viewtopic.php?f=3&t=34468&start=45#p205269

[Remember not to copy code using MS Edge.]

You will see there are issues when you close a database object and it continues to exist. You might not get an error message with older versions of TDatabase, but you could be doing things like seeking and saving to the wrong database.

I'm guessing that the error message you were getting is because you had already closed a database object, but you continued to use it. In your particular instance, it may have been working OK, but in other cases it may not. Without analyising your code I can't really guess what was happening.

You could try to find the problem in your code, by setting each object to nil right after you close it (using TDatabase ver 17.06).

oDBF:close()
oDBF:= nil

[Nages, correct me if I am wrong about this.]

Tim, if you do this one at a time then you should be able to find the database object that you are closing, then still trying to use it.

Let me know if you have questions.

James