Diego,
Instead of calling MsgInfo() please use this code: x++
that will generate an error so we can review the calls stack, thanks
Diego,
Instead of calling MsgInfo() please use this code: x++
that will generate an error so we can review the calls stack, thanks
>>>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 )
ok, thanks, in Class TDataBase remove this line:
// DESTRUCTOR td_destroy()
Also comment out this code:
/*
PROCEDURE td_destroy() CLASS TDataBase
::End()
RETURN
*/
Antonio Linares wrote:ok, thanks, in Class TDataBase remove this line:
// DESTRUCTOR td_destroy()
Also comment out this code:
/*
PROCEDURE td_destroy() CLASS TDataBase
::End()
RETURN
*/
Antonio, no errors after proposal changes.
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.
#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#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 METHOD Close() INLINE ( ::nArea )->( DbCloseArea() ), If( ::oCn == nil,,::oCn:Close() ) // FWH 13.03 METHOD Close() INLINE If( Empty( ::nArea ) .or. Empty( ::cAlias ), nil, ;
( ( ::nArea )->( DbCloseArea() ), ::nArea := 0, ::cAlias := "", If( ::oCn == nil,,::oCn:Close() ) ) )Mr. Rao, i Try yor fix in fwh1707 database, dont work, Antonio proposed fix work fine.
thanks
norberto wrote:Mr. Rao, i Try yor fix in fwh1707 database, dont work, Antonio proposed fix work fine.
thanks
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
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
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.
Nages,
I am fine with improving something. However, please consider:
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
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
Tim,
Please run the code in this message:
viewtopic.php?f=3t=34468start=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
&&