TDatabase with several DBF

[José Luis Sánchez]

Hi,

I'm updating an old program and want to use FWH Tdatabase class. I've reviewed the samples of TDatabse, but there is something that I don't understand, and is the use of TDatabase class with several DBF ¿ Can I have several TDatabase objects in my program, each attached to one DBF ? ¿ Haw can I do this ? ¿ How can I change the selected TDatabse object ?

Regards,
José Luis

[Marc Venken]

José,

Until further responses, you could look into this topic, where James has told about this issue.
He will react on your topic for sure !!

viewtopic.php?f=3&t=34310&start=15

[nageswaragunupudi]

You can use any number of DBFs with different objects.
You can also open same DBF with different objects.

Eg:
oCust := TDataBase():Open( nil, "customer.dbf", "DBFCDX" )
oStates := TDataBase():Open( nil, "states.dbf", "DBFCDX" )

? oCust:first
? oStates:name

[TimStone]

Database objects are wonderful and so easy to use.

1) Open an object, using the name you like, and then just refer to the object
2) Open other objects on the same database if you wish. For example, you may have one open for an editor of clients, but open a second one to do a quick lookup of a different account:
oCust := TDataBase():Open( nil, "customer.dbf", "DBFCDX" )
oCust2 := TDataBase():Open( nil, "customer.dbf", "DBFCDX" )
3) You can have many different objects open for different databases. Be sure to name them so you understand which ones you want to use.

James has an extension to tDatabase called tData, and another program called tRecord. The advantage of tRecord is that it saves all the field values in a buffer, and even if the pointer somehow changed on an open record, when you use the tRecord objects Save, it remembers the record number and is sure to save the data to the correct place. Also, because it is in memory, no write to the drive occurs until you actually commit with a save().

Tim

[José Luis Sánchez]

Thanks for your answer, I think that I'll be able to use the class.

Regards,

[James Bott]

José,

Not only can you have multiple databases open at the same time, but you can have multiple copies of the same database open. And you can build database objects that also contain other database objects. See this example:

http://forums.fivetechsupport.com/viewtopic.php?f=3&t=34310&sid=7105035b8916154ec3004198fe9c7663&start=15#p203884

One of the advantages of database objects is that you don't have to deal with workspaces and aliases. These are handled automatically. Also you don't need scatter/gather routines--again handled automatically. And code is much easer to read since most of it is hidden.

Code: Select all  Expand view  RUN

oCustomers:= TCustomer():New()
oCustomers:seek( cCustNo )
MsgInfo( oCustomers:Company )

You may be worried about having multiple copies of the same database open at the same time. That was something that we needed to worry about a long time ago because the hardware was so limited. Now we have large amounts of memory and very fast CPUs, so it is not much of a problem.

How can I change the selected TDatabse object?

There is no selection required. You just reference the object. Simple!

Code: Select all  Expand view  RUN

oCustomer:company
oInvoice:company
oItem:description

The first thing I suggest you do is build a class for each database that you need to use. With coding we should always try to write each bit of code only once. So with database objects you should do the same. So each database class should open the database, it's indexes and set the primary key index to the default. Then instead of doing this each time you open a database:

Code: Select all  Expand view  RUN

oCustomers:= TDatabase():New(,"cust")
oCustomers:use()
oCustomers:setIndex("cust")
oCustomers:setOrder(1)

You build a class, that does that, so then you just do:

Code: Select all  Expand view  RUN

oCustomers:= TCustomers():new()

And you can open two copies at the same time like this:

Code: Select all  Expand view  RUN

oCustomers1:= TCustomers():new()
oCustomers2:= TCustomers():new()

Or, you can open two copies of the same database using exactly the same code if they are LOCALs in different functions or classes.

Code: Select all  Expand view  RUN

function one()
   local oCustomers
   oCustomers:= TCustomers():new()
   ...
Return nil

Function two()
   local oCustomers
   oCustomers:= TCustomers():new()
   ...
Return nil

An added advantage to isolating the name, source and indexes of the database in a database class will allow you, at a later time, to switch to a new database without changing any of your code except in the New() method of the class for that object. Not just a new DBF, but a new database type like SQL. Wow, encapsulation is very useful!

I think that I'll be able to use the class.

Not only will you be able to use it, database objects will open a whole new world for you.

James

[James Bott]

José,

I forgot to provide a simple database class example. This assumes you are using CDX's and you have all the indexes in one file which is auto-opening when the database is opened (the RDD's default).

Code: Select all  Expand view  RUN

//--- Customers table class
CLASS TCustomers from TData
   METHOD New()
ENDCLASS

//---------------------------------------------------------------------------//

METHOD New( ) CLASS TCustomers
   ::super:new(, "customer" )
    ::use()
   ::setorder(1)  // default to primary key
RETURN self

Then you can just do this to create a new customer database object:

Code: Select all  Expand view  RUN

oCustomers:= TCustomer():New()

I use the plural form "oCustomers" for databases because I use "oCustomer" for a single customer object which is independent from the database object. I expect you will be wanting to do the same thing once you understand the advantages of using these two types of objects. For example:

Code: Select all  Expand view  RUN

oCustomer:= TCustomer():new(cCustno)  // create a single customer object
oCustomer:ApplyPayment( oPayment )     // pass a payment object
oCustomer:End()

Note that you can pass objects to functions or other objects without dealing with any workareas or aliases. Very useful.

Regards,
James