SalTblPopulate - why the contention ?

Discussion forum about all things Team Developer 5.x and 6.x
User avatar
Steve Leighton
Site Admin
Site Admin
New Zealand
Posts: 137
Joined: 05 Mar 2017, 20:57
Location: Tauranga, New Zealand <--> Stroud, England

SalTblPopulate - why the contention ?

Post by Steve Leighton » 15 May 2020, 23:01

Dave said: I'm not a "SalTblPopulate" user, I avoid this at any cost
Ewald said: Yes, SalTblPopulate is a nightmare
Can you please elaborate why SalTblPopulate should be avoided.
I've never had a problem - but maybe its resource related or something else ?

Also could you please explain an alternative - hopefully its not
For each row:
SalTblInsertRow() then explicitly set each column with a literal from a dB fetch !

Very interested to know why and how ..
Greetings from New Zealand
Steve Leighton

Bankside Systems Ltd.
UK ♦ Australia ♦ New Zealand

www.banksidesystems.co.uk

Image

EwaldP
Austria
Posts: 376
Joined: 07 Mar 2017, 08:00
Location: Austria

Re: SalTblPopulate - why the contention ?

Post by EwaldP » 19 May 2020, 07:18

Hi Steve,

I have an ERP-system growing from 1993 so I have all different kinds of filling child tables / table windows.

Generally speaking the problem with SalTblPopulate is the less control. We're working very extensive with ChildTables/TableWindows. Different cells/rows must be set to edit/non-edit, different formats or colors. Sometimes it's necessary to fire sql-statements on each row. I don't like to build a SQL-Statement and use SalTblPopulte and then do the other work on SAM_FetchRowDone. I want to have the code and the full control over the table in one function.

The second point is that in former days I recognized less performance with large data in filling tables with SalTblPopulate against the manual filling. So I started to use manual filling and I've never tried if the performance gap was fixed.

Third point is that the last years I try to avoid SQL-access in forms and tables and hold my data in UDVs and they don't work with SalTblPopulate.

Ewald
Ewald P. Palmetshofer
EDV-Hausleitner GmbH
4020 Linz
www.edv-hausleitner.at

User avatar
Steve Leighton
Site Admin
Site Admin
New Zealand
Posts: 137
Joined: 05 Mar 2017, 20:57
Location: Tauranga, New Zealand <--> Stroud, England

Re: SalTblPopulate - why the contention ?

Post by Steve Leighton » 19 May 2020, 11:39

Hello Ewald
Thanks for the explanation.
Greetings from New Zealand
Steve Leighton

Bankside Systems Ltd.
UK ♦ Australia ♦ New Zealand

www.banksidesystems.co.uk

Image

Dave Rabelink
Founder/Site Admin
Founder/Site Admin
Netherlands
Posts: 2924
Joined: 24 Feb 2017, 09:12
Location: Gouda, The Netherlands

Re: SalTblPopulate - why the contention ?

Post by Dave Rabelink » 19 May 2020, 12:10

So my two cents on this.

I'm in favor of having multiple layers for my applications.
Basically the multi-tier architecture would be like this:
(Each one has a particular responsibility)

- GUI layer -> how to display data, which objects to use, GUI validation
- Business layer (domain) -> how to manipulate data, calculations, business logic, validation
- Database layer -> how to store or retrieve data (databases, files, webservices etc)

Each layer has it's own particulars and different approach.

The advantage of this is that by separating the functionalities each layer is not particularly dependent on the other.
Choices or changes made on one layer minimized the need to change the other layers.

So when changing the way you store and retrieve data, for instance go from a database to files or change to a webservice, the business layer does not need to know it.
The GUI does not need to be changed as long as the domain layer is still giving the same data.

It does not matter if you display data as a table, or as a listbox or as a listview. Without changing SQL statements or changing the domain layer, switching between different ways to display the data is much easier and much more maintainable.

Another advantage is that I like to separate the application into modules (runtime files) where one module would do the data access to databases or webservices and another module stores the data in de business layer. Any other module to display the data could access the domain. So multiple GUI's having different GUI objects can use the same set of data to display it.

For small applications which have a more 1:1 database to GUI design, I can imagine that functions like SalTablePopulate are easy and enough. But maintenance will be much harder when the application changes and eventually need more and more advanced features which will give you problems when SalTablePopulate does not support what you need.

A disadvantage is that you need to think/design your application early in development. So it will take more time to get something running. This disadvantage will become less and less when the application gets more and more maintenance in future and historical choices for database brands and GUI design changes.

So even on simple applications I try not to rely on those one-tier functions like SalTablePopulate
Regards,
Dave Rabelink

Image
Articles and information on Team Developer Tips & Tricks Wiki
Download samples, documents and resources from TD Sample Vault
Videos on TDWiki YouTube Channel

FRBhote
India
Posts: 2216
Joined: 09 Mar 2017, 05:32
Location: Hyderabad, India

Re: SalTblPopulate - why the contention ?

Post by FRBhote » 16 Jun 2020, 12:15

I use SalTblPopulate quite a lot - saves the assignment of a variable to a column.

But the drawback on TD 2.1 is that a break on SAM_FetchRowDone causes the system to hang and have to kill the application.

Wonder if it happens on newer versions.

Return to “General Discussion”

Who is online

Users browsing this forum: [Ccbot] and 0 guests