Tdata still Up to Date ?

[Marc Venken]

Hello all,
Mr. James,

Looking and reading posts lately almost convinced me of using Tdata.
I a post from 3/2016 I read that there are some problems that arrive as FWH is evolving, but Tdata is not? as far as I can see.

SO, if using a class, use Tdatabase that is FWH evolving? What is the future of Tdata?

Or will Tdata becoming a part of FWH ?

Marc,

Re: More 16.01 problems with xBrowse UPDATED
Postby TimStone » Mon Mar 07, 2016 7:27 pm

I have further isolated the problem. I switched from using the tdata class extension, and went to strictly tdatabase. That resolved the problem.

So now I have to find what, in tData is causing a problem. It will relate to revisions made in tDatabase that may now render my version problematic. Since this could have repercussions elsewhere ( tdata is used throughoutout ), I will get in touch with James.

Tim
Tim Stone
http://www.MasterLinkSoftware.com
tim@gtstone.com
Using: FWH 16.11 with Harbour 3 / Microsoft Visual Studio Pro 2015

[TimStone]

I forgot what the problem was, but I think it ultimately was somewhere else.

I use tData extensively and I have no problems with it. I also use the tRecord extension, and sometimes the tSearch.

Tim

[James Bott]

Marc,

Yes, Tim did have some issues back then, but they turned out not to be with TData. I only remember one instance, way back, when something that was changed in TDatabase did cause a problem with TData, but it was easily fixed.

TData hasn't been updated since 2006, because I haven't found any need for an update. It is still working fine. This is one of the advantages of OOP and inheritance. Note that TData uses TDatabase as its parent class, so new features that are added to TDatabase are automatically inherited by TData.

TData comes with a TRecord class which allows you to create objects like an invoice, customer, transaction, item, vehicle, purchase order, work order, etc. The list goes on.

Note that objects created by TDatabase and TData are tables of items, not items themselves.

To get the maximum benefit you will have to do some studying of Object-Oriented Programming (OOP) relating to real world objects. Granted, FW is OOP but relates mostly to interface objects. Using real-world objects in OOP opens up a whole new world to you as a programmer. Imagine:

Code: Select all  Expand view  RUN

oCustomer:= TCustomer():New( cCustNo )
msgInfo( oCustomer:balance )
oCustomer:applyPayment( nAmount, dDate )
msgInfo( oCustomer:balance )
oCustomer:End()
 

Note that the method applyPayment() could be a complex process like subtacting an amount from one or more invoice objects, and updating the customer's balance. Note also how easy it is to read and understand OOP code.

Have you read my articles about OOP available here:

http://gointellitech.com/program.html

Regards,
James

[Marc Venken]

Thanks James,

I' Will be reading first the OOp files on your site.

[James Bott]

Marc,

OK, I know OOP seems overwhelming. But how is this for simple?

Here is the entire customer class that adds the addPayment() method. It inherits from my TRecord class.

Code: Select all  Expand view  RUN

//--- Customer class
CLASS TCustomer from TRecord
   METHOD New()
   METHOD ApplyPayment()
    METHOD End()
ENDCLASS

METHOD New( cCustNo ) CLASS TCustomer
   ::oTable:= TCustomers():New()
   ::oTable:seek( cCustNo )
   ::Load()
RETURN Self

METHOD End() Class TCustomer
    ::oTable:end()
Return nil

METHOD ApplyPayment( nPayment ) CLASS TCustomer
   ::balance:= ::balance - nPayment
   ::save()
RETURN nil
 

Then it only takes two lines of code to apply a payment.

Code: Select all  Expand view  RUN

  oCustomer:=TCustomer():new( cCustNo )
  oCustomer:applyPayment( nPayment )
 

Notice how easy it is to read and understand. What you don't see is all the code it inherits. You don't have to deal with workareas, opening databases, alias referencing, buffering data, record locking and record locking failures, etc.

James

[Enrico Maria Giordano]

James,

if I'm not wrong, you also have to open and activate the correct index for the Seek() method to work.

EMG

[Marc Venken]

Marc,

OK, I know OOP seems overwhelming. But how is this for simple?

Here is the entire customer class that adds the addPayment() method. It inherits from my TRecord class.

Notice how easy it is to read and understand. What you don't see is all the code it inherits. You don't have to deal with workareas, opening databases, alias referencing, buffering data, record locking and record locking failures, etc.

James

James, I'm not ready yet for this.... I'm in a copy/paste from samples and build around that. If I copy/Paste this into a program of mine, I have unresolveds because they need to be linked in, or put somewhere else than simply as a function in my program. Is there also a sample in the samples dir of FWH ? I diidn't see it yet.

[James Bott]

Enrico,

if I'm not wrong, you also have to open and activate the correct index for the Seek() method to work.

Yes, of course, you are correct. This is done automatically in the TCustomers class. As a standard the first index is always the primary key.

Code: Select all  Expand view  RUN

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

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

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

I am using CDX's in auto-open mode, so I don't have to open the indexes separately.

I haven't done this yet, but because this is common code for every table, I should make a subclass of TData and move this code into that class.

Code: Select all  Expand view  RUN

::use()
::setOrder(1)

Then inheriting from that class, the New Method for a table would simply be:

Code: Select all  Expand view  RUN

METHOD New() CLASS TCustomers
   super:new(, "arcust")
RETURN self
 

As I expect you know, finding common code and moving it up in the hierarchy means that you have to write less and less code in the lower level classes. Another great advantage is that if you need to change that common code, you only have to do it in one place.

James

[James Bott]

Marc,

James, I'm not ready yet for this.... I'm in a copy/paste from samples and build around that. If I copy/Paste this into a program of mine, I have unresolveds because they need to be linked in, or put somewhere else than simply as a function in my program. Is there also a sample in the samples dir of FWH ? I diidn't see it yet.

OK, I was not clear, these examples only work with my TData and TRecord classes.

As I mentioned in my previous message to Enrico, the more code you can move up into higher level classes, the less code you have to write later. You have to look for common code then move it up. Usually, this is not easy because code to do the same thing may have been written quite differently in different places. It can be quite a puzzle and take lots of trial and error. I can't imagine how many hours I spent on just those two classes, but now I write a lot less code to do the same things.

James

[TimStone]

I've made setting the index a bit easier.

Code: Select all  Expand view  RUN

METHOD New( nOrd ) CLASS TCustomers
   super:new(, "arcust" )
   ::use()
   ::setorder( nOrd )  // set to requested key
RETURN self
 

Passing nOrd ( the index number ) opens the file using the desired index with the one program line. I often have multiple indexes, but I can open a file for any purpose with the proper order set, with a single line of code. It really made a significant difference in my primary application that I sell.

Tim

[nageswaragunupudi]

I haven't done this yet, but because this is common code for every table, I should make a subclass of TData and move this code into that class.

Code:
::use()
::setOrder(1)

If this is what a programmer wants in general, he can also set the global setting

Code: Select all  Expand view  RUN

SET AUTORDER TO 1
 

All DBFCDX files, when opened, will set index to order 1, if index is available.

[James Bott]

Tim and Nages,

Thanks to both of you for your ideas. I think defaulting nOrd to 1 might be the best solution. If nOrd is not passed, the order defaults to 1, or you can pass any other order.

Code: Select all  Expand view  RUN

METHOD New( nOrd ) CLASS TCustomers
   Default nOrd:= 1
   super:new(, "arcust" )
   ::use()
   ::setorder( nOrd )  // set to requested key
RETURN self 

So, you can do this:

Code: Select all  Expand view  RUN

oCustomers:= TCustomers():new()

or,

Code: Select all  Expand view  RUN

oCustomers:= TCustomer():new( 3 )

One line does it all.

James

[James Bott]

Marc,

Here is a sample customer class that inherits from FW's TDatabase class. You can test this to get a feel for creating classes.

However, you don't get all the features of TData, nor can you create single objects like oCustomer, oItem, oInvoice, etc., which require the TRecord class.

James

Code: Select all  Expand view  RUN

/*
Purpose  : Sample customer table class. Inherits from TDatabase class.
Author   : James Bott, jbott@compuserve.com
Date     : 05/26/2017
Company  : Intellitech
Language : Fivewin/xHarbour
Updated  :
Notes    : Example for Marc Venken

*/

#include "fivewin.ch"

Function Main()

   Local oCustomers

   // Set RDD defaults
   SET EXCLUSIVE OFF
   SET(_SET_AUTOPEN, .T. )    // Auto open cdx-file
   REQUEST DBFCDX
   rddsetdefault( "DBFCDX" )

    // Index the database if not existing
    // The CUSTOMER.DBF database is from the FW\samples directory
    // Note that it is not a good example since it has no CUSTNO field
    // We are using FIRST instead of CUSTNO as the primary key just for testing
    if .not. file("customer.cdx")
       use customer
       index on upper( first ) to customer
       use
    endif
   

    // Create a table of customers
   oCustomers:= TCustomers():New()

    cCustNo= upper("John")     // Faking the CUSTNO
    oCustomers:seek( cCustNo )
   
   msgInfo( oCustomers:last, "Customer No." )

    oCustomers:end()

Return nil

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

CLASS TCustomers from TDatabase
   METHOD New()
    METHOD End()
ENDCLASS

Method New() Class TCustomers
   super:new(,"customer")
   ::use()
   ::setorder(1)  // set to primary key by default
Return self

Method End() Class TCustomers
    ::use()
Return nil

// EOF

[Marc Venken]

James,

I get this error. should I link something more ? I put the prg in the sample folder en build like all samples.

Application
===========
Path and name: C:\fwh1604\fwh\samples\james.exe (32 bits)
Size: 3,750,912 bytes
Compiler version: Harbour 3.2.0dev (r1601050904)
FiveWin Version: FWH 16.11
Windows version: 6.1, Build 7600

Time from start: 0 hours 0 mins 0 secs
Error occurred at: 05/27/17, 23:48:13
Error description: Error BASE/1003 Variable does not exist: SUPER

Stack Calls
===========
Called from: james.prg => TCUSTOMERS:NEW( 56 )
Called from: james.prg => MAIN( 37 )

[nageswaragunupudi]

However, you don't get all the features of TData, nor can you create single objects like oCustomer, oItem, oInvoice, etc., which require the TRecord class.

It would be greatly informative to all if you can please explain:
1) What are the important features of TData which we can not get with TDataBase?
2) What is that TRecord can do what TDataRow can not do?
We would be very much glad if you can show some illustrations of using TRecord to create single objects.