Database - 17.07 - Problems

[TimStone]

I have used tData and tRecord for years with great success. I've followed the threads about adding capabilities to tDatabase that are similar to tData, and the notes indicate you have done that in 17.07. However, I now am having problems related to databases that suddenly appeared with this version.

I will explore this in depth to resolve the issues. However, until that time, can I simply link in the working database.prg source from 17.06 for now or have you integrated the new database into other areas of the program like xbrowse that require the new version ?

Thank you.

[Antonio Linares]

Tim,

> I now am having problems related to databases that suddenly appeared with this version

What problems are they ? Could you provide an example to reproduce it ?

> can I simply link in the working database.prg source from 17.06

Yes, please. Try it and lets see if that makes a difference

[TimStone]

Antonio,

Let me first state that this is ABSOLUTELY a problem with tDatabase ( database.prg ). I linked the 17.06 database.prg with my source code, and the FWH 17.07 libraries, and the problem I am tracking did not occur. With repeated testing, it still does not appear. However, with 17.07 database.prg ( in the library ), it happens every single time. So the ONLY variable here is the database.prg file ( tDatabase class )

Let me explain a bit of what is happening. I use tData as a class inheriting from tDatabase, and tRecord. I'm working with an invoice master file. Each record contains data ( often linked to other files ) with all of the information related to that invoice ( parts, labor, recommendations, revisions, totals, notes, client and service item, etc ).

The records are in a primary invoice file, and that list of open invoices is browsed. When one is selected to work on, it is opened at a tRecord object. Immediately all of the field data is stored into memory where it can be edited, and when finished, saved back to the main file.

With 17.06, I can browse the file, and select the desired invoice. I then open it as an individual record object and do all of my editing. When I go to exit it, the object is closed. I then select another record in the list and open it. When I close it, the same process takes place. My clients have been doing this all day long for years and never a problem.

Now we have 17.07. The first record works fine. However, after I close the first record and open the second, it initially appears that the data is there, but when I go to close it, the record object actually has nil values. I discovered this because a test is run before actually performing a save on the close. This is a critical error.

By linking in 17.06 database.prg, with absolutely no other change to the code, all works perfectly again.

My thought is that there is a problem with the buffers used in the new database.prg. I have looked at the code differences, and they are extensive. It appears that Nages is combining SQL and DBF code and that may be complicating the process too much.

I will have to write some test code, but it will not exactly be simple. I will try to do it in the next day or two. However, perhaps those who contributed to the many changes in that class could review them to see if there are obvious errors. My biggest concern is that other classes may depend on data from this one ( ie. xbrowse ) and soon my 17.06 version will not be sufficient to allow other elements of FWH to work properly.

Tim

[nageswaragunupudi]

It appears that Nages is combining SQL and DBF code and that may be complicating the process too much.

The sql functionality was there for many years and is not used unless program calls the method SqlQuery() explicitly. Since you are not using it it should not concern you at all.

TDatabase does not know anything about TRecord class of TData library. New method Record() simplifies creating TDataRow object which has been working for years. It just makes the creation simple and enhancement is that it now covers virtual and aliased columns also. In any case you are not using TDataRow.

If you are using TRecord class it should work the same way as before.

We shall be glad to have a sample that reproduces any problem using TDatabase directly.

[TimStone]

When I have the opportunity to build a sample I will post it. However, it uses tData and tRecord which I purchased from James. I have been in communication with him on this also.

The clear, undisputable, fact is that 17.06 database.prg works perfectly, and 17.07 database.prg does not. I have compared the two versions of code and see many changes, some of which I have not had the time to study for full understanding. I will be doing that more in a few days.

It is my hope that others who use data objects can report on this if they have moved to 17.07. Since I have seen no comments yet, I assume either they are not using data objects, or they have not moved to 17.07.

I just know I had to revert the database.prg to have a testable, and distributable, update to my clients which is my top priority right now.

Tim

[norberto]

I use Tdata from james, i have the same problem.
Looks like the changes made in latest build close the database. I went back to fwh1705.

[James Bott]

Norberto,

Can you provide a small sample program that shows the error? I have not yet been able to recreate the error here.

Are you using TRecord also?

Regards,
James

[norberto]

James, I have a legacy program, there have been no changes in the last few months, in this I use only tdata, compiling as 1705 works fine, but with 1707 an error occurs when leaving the screen of browse using Tdata. Since there have been no changes in recent 6 months, and works well in 1705, so can be something altered in database.prg. It's tricky to make a little and self contained program, but I'll try.

thanks for your time.

[James Bott]

Norberto,

Yes, I don't doubt that something that was changed in the TDatabase class is causing the problem but I have been unable to duplicate it here. That is why I am trying to find the code that shows the problem so I can address it with changes to TData.

If you can find the section of code in your program where the problem occurs, that will help. Better yet, if you can write a small test program, that would help even more.

There is also another possibility and that is that TDatabase if used in the same code (without TData) the same error might occur. We need to find out the answer to this also.

Thanks,
James

[norberto]

James, after open the same dialog two times , i have the error with fwh1707, in 1705 work fine:

error description error DBCMD/2001
workarea not in use : ordscope

called from : +> ordscope(0)
called from : => Tdata:setscope(0)
....

This problem is not reported to this topic :

viewtopic.php?f=3&t=34337&p=203721&hilit=odbf%3Aend#p203721

Because apparently the database was closed.
Anyway I will try to reproduce the error using your examples of tdata, making a small , self contained sample.
But until this, I'm using database of fwh1705 with fwh1707 and its work.

thanks

[James Bott]

Norberto,

James, after open the same dialog two times , i have the error with fwh1707, in 1705 work fine:

Do you mean you open it, then close it, then open it again? Or, open it, then switch to another screen, then switch back?

I have tried opening the same database twice and I don't get an error.

Code: Select all  Expand view  RUN

   oCustomers:= TCustomer():new()
   oCustomers2:= TCustomer():new()
   
   oCustomers:skip()
   
   oCustomer:= TRecord():new(oCustomers)
   
   msgInfo(oCustomer:company,"oCustomer:company" )

You are right to bring up the other message regarding adding an End() method. This was a change, yet TData has always had it's own Close() and End() methods, so it seems unlikely that that change is the issue. Still it is possible.

James

[norberto]

james,

Do you mean you open it, then close it, then open it again?

yes. open a dialog with object database, close, open again, error with 17.07, work fine with 17.05.
I use odat:close() in end of dialog.

thanks

[TimStone]

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.

I think the problem is related to the tDatabase class and the changes made within. Why ?

1) The process worked perfectly in 17.06
2) Extensive changes were made in 17.07
3) The program FAILS to work properly in 17.07. OUR SOURCE CODE REMAINS EXACTLY THE SAME.
4) WHEN I LINK IN database.prg from 17.06, and ALL OTHER libs are from 17.07, the problem goes away. If the problem were in some other class or function, this would not occur because they all still have the 17.07 changes.
5) The focus needs to be on the CHANGES from 17.06 to 17.07 in database.prg

[James Bott]

Tim,

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.

OK, I have added a save() and End() to the TRecord object (to the code I previously sent you) and I am still not getting the error. I haven't tried it with a browse yet, because I wanted to keep it simple. Maybe the browse is creating the problem.

James

[Diego Decandia]

I have not found any problems with TData.
Then I tried XBrowse, and, even without using TData, sometimes, not always, coming out and reopen a dialog containing XBrowse, it do not close the DBF because it is already closed (from XBrowse?).