tables

Scotte Meredith spomacguy at gmail.com
Tue Mar 14 17:23:40 UTC 2023


> 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.

I have only found 1 valid use of a code class in Studio: using it with an error handler.

A code class takes you out of "instance space". Your variables are not confined to an instance of a window, menu, etc. and so you can get leakage between different pieces of the program. The CRB does this, making fields global. Now there are good uses for the CRB still, but not in the old-style way of having globals where changing a value in one window can have far-reaching side effects in other windows. There are better ways.

> 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.

I hit this in my previous email I just sent a few minutes ago.

> 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.

You can have the parent table contain the lists for the children within that table class as their own instances of other table classes and let the parent class take care of inserting/updating in the appropriate manner. Or, as I prefer, in an object class that contains any table classes it needs. The object class is associated with a particular window(s) and does all the data management for the window. Each of the table classes referenced within the object does its own thing with the table, so the table classes are associated with any object class for any window. 

Think of it as Lego bricks that you can drop in to provide a widget joint. Then you can put various widget joint into a larger widget to perform another function. By combining all of these in the right way you end up with a model of the space station.


> 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?

There is an understandable confusion about the terms "schema" and "table". A schema class is certainly associated with a database schema, but they are not one and the same. A schema class has a number of methods for working on a particular database table and you cannot change those methods. A table class is not the same as a table in Postgres. It allows you to override and expand the built-in schema classes you associate with it. Similarly, the term "list" in Omnis has always been used for multiple things. It can be a field on a window, or a data construct within any code that can be manipulated whether you have a window field associated with it or not. That one we old-timers have under our belts, but was very confusing when first starting out.

I would not try using a query with a schema as a way to update multiple database tables at the same time until you have been using this for awhile. You can do it, but you need to understand what's going on under the hood a bit more before trying this. It can be quite effective, but not when you are starting out.




Scotte Meredith
spomacguy at gmail.com
509/998-0991



More information about the omnisdev-en mailing list