Mr James
METHOD Close() is the same from 13.03 till 17.07 (without fix)
Regards
G. N. Rao.
Hyderabad, India
G. N. Rao.
Hyderabad, India
FiveTech Support Forums
FiveWin / Harbour / xBase community
Board index FiveWin for Harbour/xHarbour Database - 17.07 - Problems
Mr James
Very Good Example.
After noticing the issue with Close() method, we undertook review of all other important methods and we too noticed the issue demonstrated by you in your example. Imagine the dangers of oStates:FieldPut( 1, "xy" ) which corrupts customer.dbf and programmer does not know this.
Here is another similar example:
Apart from advising the programmer what to do and what not to do, it is more important to improve the safety of tdatabase class. This is implemented in 17.08. If you example is tried with 17.08, oStates:GoTop(), oStates:FieldGet(1), oStates:FieldPut(), etc. produce runtime error as they should.
The same example runs without runtime errors with all versions upto 17.07, with all its hidden/unnoticed dangers but will produce runtime errors with 17.08. It does not mean that the problem is with 17.08. It only protects unsafe code from execution.
Explanation: So far tdatabase uses ( ::nArea )-> for access. There is possibility, however rare, that another DBF is opened by the application in the same ::nArea without knowledge of the object (also means without programmer's knowledge) and the object starts working on a different DBF. We resolved this issue by changing ( ::nArea )-> with ( ::cAlias )-> and managing the alias naming system to avoid any possible repetitions.
We also noticed another issue with METHOD Use(). Multiple calls to Use() when the object is already open, result in orphaning the present alias/area and opening the same dbf in a new area/alias. This is also fixed in 17.08. Second and subsequent calls are ignored. With all these modifications, it is now possible to reopen dbf by calling Use() after closing with Close().
From 17.07 it is also possible to close the dbf by setting oDbf := nil. In addition to closing dbf, it also avoids possible inadvertant use of a closed object. This is a much safer way to close dbf than calling Close()/End().
Very Good Example.
After noticing the issue with Close() method, we undertook review of all other important methods and we too noticed the issue demonstrated by you in your example. Imagine the dangers of oStates:FieldPut( 1, "xy" ) which corrupts customer.dbf and programmer does not know this.
Here is another similar example:
oStates := TDataBase():Open( nil, "STATES" )
? oStates:nArea, oStates:Code, oStates:Name // 1, "WA", "Washington"
USE CUSTOMER // By mistake
oStates:GoTop()
? oStates:nArea, oStates:Code, oStates:Name // 1, "Homer", "Simpson"Apart from advising the programmer what to do and what not to do, it is more important to improve the safety of tdatabase class. This is implemented in 17.08. If you example is tried with 17.08, oStates:GoTop(), oStates:FieldGet(1), oStates:FieldPut(), etc. produce runtime error as they should.
The same example runs without runtime errors with all versions upto 17.07, with all its hidden/unnoticed dangers but will produce runtime errors with 17.08. It does not mean that the problem is with 17.08. It only protects unsafe code from execution.
Explanation: So far tdatabase uses ( ::nArea )-> for access. There is possibility, however rare, that another DBF is opened by the application in the same ::nArea without knowledge of the object (also means without programmer's knowledge) and the object starts working on a different DBF. We resolved this issue by changing ( ::nArea )-> with ( ::cAlias )-> and managing the alias naming system to avoid any possible repetitions.
We also noticed another issue with METHOD Use(). Multiple calls to Use() when the object is already open, result in orphaning the present alias/area and opening the same dbf in a new area/alias. This is also fixed in 17.08. Second and subsequent calls are ignored. With all these modifications, it is now possible to reopen dbf by calling Use() after closing with Close().
From 17.07 it is also possible to close the dbf by setting oDbf := nil. In addition to closing dbf, it also avoids possible inadvertant use of a closed object. This is a much safer way to close dbf than calling Close()/End().
Regards
G. N. Rao.
Hyderabad, India
G. N. Rao.
Hyderabad, India
We also noticed another issue with METHOD Use(). Multiple calls to Use() when the object is already open, result in orphaning the present alias/area and opening the same dbf in a new area/alias. This is also fixed in 17.08. Second and subsequent calls are ignored. With all these modifications, it is now possible to reopen dbf by calling Use() after closing with Close().
Are you saying that we can no longer have two objects opening the same .dbf ? Thus the following would no longer work ?
oStates := TDataBase():Open( nil, "c:\fwh\samples\states.dbf", "DBFCDX", .t. )
oStatesAlt := TDataBase():Open( nil, "c:\fwh\samples\states.dbf", "DBFCDX", .t. )Sometimes, when adding data to an open file, it is helpful to open a new object and do a lookup of data on that same file. If "subsequent calls are ignored" to a .dbf, then that would break this capability.
In a previous post you said we could do this ( http://forums.fivetechsupport.com/viewtopic.php?f=3&t=34394&p=204172&hilit=tdatabase#p204172) but your comment here now suggests otherwise.
Tim
Tim Stone
http://www.MasterLinkSoftware.com
http://www.autoshopwriter.com
timstone@masterlinksoftware.com
Using: FWH 23.10 with Harbour 3.2.0 / Microsoft Visual Studio Community 2022-24 32/64 bit
http://www.MasterLinkSoftware.com
http://www.autoshopwriter.com
timstone@masterlinksoftware.com
Using: FWH 23.10 with Harbour 3.2.0 / Microsoft Visual Studio Community 2022-24 32/64 bit
oStates := TDataBase():Open( nil, "c:\fwh\samples\states.dbf", "DBFCDX", .t. )
oStatesAlt := TDataBase():Open( nil, "c:\fwh\samples\states.dbf", "DBFCDX", .t. )This is perfectly valid and we can open the same dbf any number of times.
What I discussed about the Use() method is totally different and has nothing at all to do with the freedom of the programmer to open the same database unlimited number of times.
Let us consider this case to understand the effect of multiple call of Use() method.
#include "fivewin.ch"
REQUEST DBFCDX
function Main()
local oStates
oStates := TDataBase():Open( nil, "STATES", "DBFCDX", .t. )
? oStates:nArea, oStates:cAlias // --> 1, "TDF"
oStates:Use() // Called when oStates is already open
? oStates:nArea, oStates:cAlias // --> 2, "TDF001"
oStates:Close() // Closes Area 2 Alias "TDF001"
// oStates is not aware that Area 1 (Alias TDF) is still open
// Even we do not know
// This remains open like this till the application is closed.
// If we now try to open STATES.DBF exclusively, the call fails.
return nilThis is fixed in 17.08
Regards
G. N. Rao.
Hyderabad, India
G. N. Rao.
Hyderabad, India
Nages,
Are you saying that you are now NOT destroying the object when Close() or End() is called?
James
With all these modifications, it is now possible to reopen dbf by calling Use() after closing with Close().
Are you saying that you are now NOT destroying the object when Close() or End() is called?
James
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Okay, we have a bug since fwh13.03 finally discovered now. I'm sure several users of tdabase are wondering: Should I check out my databases, my invoices, bills for errors?
What leads me to think: when these changes are made, they are tested in real-world applications, with hundreds of records, files, users, or are tested and introduced in a small, self contained sample?
I know that bugs exist in all languagues and tools, are Introduced and resolved everyday, but in my specific case , that I have a legacy application, with hundreds of lines, and that my subscription for updates of FWH finalized previous month, what should I do? Back to FWH13.03? Am I going to have the fix for this problem?
What's the latest safe version of FWH for me to compile my application today? or proposed fix for Nages, James, Antonio is ok?
Norberto,
Just because we have found that it is possible to make an error, unless you have been having crashes with error messages, I think problems with your app are unlikely. And your users would be reporting them.
Some of the things we have shown are not things you should be doing in your code. For instance saving data directly to a field number--you presumably are using the Save() method which would crash if it was trying to save to the wrong database.
So, for now, I would stick with ver 17.06 or earlier.
James
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
James, thank for your time, im using fwh17.07 with tdatabase from 17.05 and tdata without errors, but my question is : My data is safe? I run the risk of being recording in incorrect database? i should put odat:=nil after odat:close()?
very thanks
Norberto,
That was what I was trying to say in my last message.
I don't know how you write your code, but unless you are doing something like:
oStates:FieldPut(1, cName)
Instead of:
oStates:name:= cName
oStates:save()
Then you are not going to have problems with saving to the wrong database. If oStates was using the workarea of oCustomer and you did oStates:save() the program would crash because the fieldnames of the two databases are different.
The test code Nages and I have been writing is not real-world stuff, but just code to try to see what is going on behind the scenes.
And, yes, setting each database to nil after closing it, is OK--for now. But, when we are sure the destroy method is working properly, then setting them to nil will cause an error (since the object no longer would exist). When the destroy method is working, then you may see some problems with existing code that may have been working OK before. If you do get problems, it points out issues in your code. Yes, the code was OK before, but may or may not have been working correctly.
Don't feel like I am singling you out, Norberto, we probably all have unsafe code that we will have to fix. But the advantage will be that the programs will be much safer.
James
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
James, thanks, i use like your samples of tdata, so im safe.
very thanks again
norberto