tables

[Doug Easterbrook]

hi Daniel

others have said it .     so I’ll reinforce the notion with an example.



TABLE CLASS PER TABLE

You ABSOLUTELY want to have a table class for each table in your database (one defined for each table).   so if you have order, client and inventory tables, you will have at least 3 table classes  (plus likely table classes for each link table).


TABLE CLASS SUPER CLASS
You will want one more table class that is the ’Superclass’ for all the table classes that all others inherit from.


WHAT GOES INTO EACH

In the superclass ’table’ you will have all the code that is common to all tables (like your $insert, $update, #delete code that you have over ridden)

you’d write it in such as way to use $cinst.$servertables  etc.   and the code would be generic so that it applies to all your activity. regardless of tables.    Thats the foundation of Object orientation.


in each child table class, you’d have methods that pertain only to each specific table.


For example, in the main superclass table, I might have a method called $verifyRecord.  That makes sense, in that I need to verify that the data is correct before putting it into the database.

the Superclass table would have a $verifyRecord that contained

# you must Over ride this for each table
BREAKPOINT
quit method kfalse


in the table for orders, you’d over ride $verify to have edit checks on the data that are pertinent to the fields in that specific table.  I.e. the edits below are simplistic to give the idea, but only apply to the ‘order tab’e’.    the ones for client table class would be different.   but at least you’d know where to find the edits for each tabel

parameter ‘errorMessage'
If $cinst.ORD_NUM=0
  calculate pErrorMessage as ' it is a bad thing to have orders numbers that are zero’)
  quit method kfalse
end if
If isclear($cinst.ORD_DATE)
  calculate pErrorMessage as ' it is a bad things to have empty order dates’)
  quit method kfalse
end if
quit method kTrue





THE GLUE THAT TIES THEM TOGETHER


if you defines a tableclass, you can use inheritance to save a lot of coding.   eg


do list.$defineFromTableClass(‘orders’)
do list.$fetchRecords(‘all orders in past week’)

for list.$line from 1 to list.$linecount
 do list.$verifyRecord (errormessage) returns flag
 if flag false
   ok message [errormessage]
end if
end for.




the cote above is pretty much exactly the same for editing any table in the database (because of object oriented programming concepts).


it makes it simpler to maintain.    and you can have many instances of the same table class if you want.  i.e. you can have multiple windows that read order records.  and the data will be encapsulated — so one ‘copy’ of the table will not interfere with the others.

as you build up your table classes, you will find that you tend to do the same kinds of things to each record.    for example:
- you will always verify data
- you might get the children of record (i.e, for an order, you might get the items sold on it)
- you might delete the records ($delete)
- you might email the data to people
- you might export the data to excel


far easier to use the following after efining the lsit

do list.$exportToExcel


and that might be common code that all tables could use.







what ever you do, DO NOT put your database  code into code classes or behind windows.




Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug at artsman.com
http://www.artsman.com
Phone (403) 650-1978

> On Mar 14, 2023, at 9:24 AM, Daniel Sananes <daniel.s at kopparbergs.se> wrote:
> 
> Good afternoon, or what it might be somewhere else,
> 
> Pardon my ignorance but I find this table-thing interfering with my logical thinking.
> 
> I am really starting to wonder what the difference is using the table-approach or just have the same code somewhere else, maybe in a code-class.
> The Table is the list, somehow and sort of, but I could as well just call a method in a code-class and send the list in there.
> The $defienfromsqlclass seems to me just be the same as $schemas.SCHEMA.$makelist.$objs(ref.$name) returns LIST.
> Or is there something else in this I do not understand. Apart from that the command invokes a table.
> 
> If I have an order-window and are to create an order I will:
> 
>  1.  Press a button called New order
>  2.  I will find a client that the order belongs to
>  3.  I will find articles that belongs to the order. These will be orderrows.
>  4.  When finished the setup, I will press create the order.
> Am I supposed to have 3 tables working at the same time?
> The order has to be saved/inserted into the database with a new primary key and the foreign key for the clients primary key has to be calculated.
> Then the orderrows has to be saved with the FK from the orders PK. And new PK's has to be calculated for the orderrows/records.
> How would the setup be with the table-approach?
> I don't get it.
> Do I do 2 $inserts using 2 tables, one after the other? One for order and one for orderrows.
> 
> If $cinst.$servertablenames is a query there will be several schemas to handle.
> I would say the schema is like the Omnis7 file format.
> 
> $cinst.$servertablenames can contain several schemas (from query). How would a table handle $insert or $update when there are several schemas?
> I would process each schema, building my own lists with $makelist, one after the other, with correct SQL. Why do I have to have that code in a table?
> 
> /Daniel
> 0736 704070
> 
> _____________________________________________________________
> Manage your list subscriptions at https://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com