Database - 17.07 - Problems

[nageswaragunupudi]

Mr James

METHOD Close() is the same from 13.03 till 17.07 (without fix)

[nageswaragunupudi]

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:

Code: Select all  Expand view

  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().

[TimStone]

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 ?

Code: Select all  Expand view

   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

[nageswaragunupudi]

Code: Select all  Expand view

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.

Code: Select all  Expand view

#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 nil
 

This is fixed in 17.08

[James Bott]

Nages,

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

[norberto]

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?

[James Bott]

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

[norberto]

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

[James Bott]

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

[norberto]

James, thanks, i use like your samples of tdata, so im safe.

very thanks again

norberto