tables

[Scotte Meredith]

A transaction is a thing in SQL where you begin a transaction, do a bunch of SQL statements and then if they all succeed you commit them. If not they all roll back. You couldn’t do that with the Omnis data file. 

Imagine if your bank ran some SQL and all the checks were taken out of your account and they worked but the deposits didn’t. 

That’s why you use transactions. 

Sent from my iPad

> On Mar 18, 2023, at 3:15 PM, Daniel Sananes <daniel.s at kopparbergs.se> wrote:
> 
> Great Scotte,
> I understand the scenario you put forward.
> In not a so far away galaxy this will be a thing I will test when I start studying objects.
> 
> You say one single transaction.
> I believe this does not mean one sql-statement to the database? Or?
> 
> Thanks
> Daniel
> 
> -----Ursprungligt meddelande-----
> Från: omnisdev-en <omnisdev-en-bounces at lists.omnis-dev.com> För Scotte Meredith
> Skickat: den 18 mars 2023 22:53
> Till: OmnisDev List - English <omnisdev-en at lists.omnis-dev.com>
> Ämne: Re: tables
> 
> So here's a possible scenario off the top of my head:
> 
> oMyOrderObject
> -- tOrderHeader
> -- tOrderRow
> -- tCustomer
> -- tStockItem
> 
> You instantiate oMyOrderObject as ioMyOrderObject. Inside you have a row for the order header, list of the order rows, row for customer, list for stock items.
> 
> Your window fields point to those rows and headers.
> 
> Have methods:
>  ioMyOrderObject.$getCustomer
>  ioMyOrderOjbect.$getStockItem
>  ioMyOrderOjbect.$saveOrder
> 
> $verifyOrder makes sure you have the customer record, there is enough stock available for all the order rows and returns something if they don't all match up $saveOrder copies the customer key into Order header, decrements the stock items. Then saves order header and gets the key, stuffs that key into each of the order rows and saves them, then saves the stock items to update the available stock. Do that all in a single transaction.
> 
> The tOrderHeader might have a method $getByPK that does the SQL to pull up a record from a primary key. Or others to do other searches, so you could do that SQL within the table class as a separate set of methods.
> 
> So to quote Tolkien:
> "One object to rule them all, one object to find them, one object to call the tables classes and in the database bind them. In Postgres, where the data lies."
> 
> 
>> On Mar 18, 2023, at 12:51 PM, Daniel Sananes <daniel.s at kopparbergs.se> wrote:
>> 
>> Hi Scotte
>> 
>> Would the object class have one $definefromsqlclass for the order-header and one for the orderrows?
>> And "helper table classes" for client.
>> In this case there would be 3 different $definefromsqlclass all assigned inside the object.
>> Then with returning-clause one would get the PK for the different datatables?
>> 
>> Is there correct OO to perform code inside a table to get values that do not belong to the table-instance?
>> I am almost not understanding my own question here.
>> 
>> Another question, are there situations where you would not use the table-instances but perform sql outside the table?
>> Do I understand this question? Maybe...
>> 
>> Regards
>> Daniel
> 
> 
> 
> Scotte Meredith
> spomacguy at gmail.com
> 509/998-0991
> 
> _____________________________________________________________
> Manage your list subscriptions at https://lists.omnis-dev.com Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
> VARNING: Det här e-postmeddelandet kommer från en extern avsändare. KLICKA INTE på länkar eller bilagor om du inte känner igen avsändaren och vet att innehållet är säkert.
> _____________________________________________________________
> Manage your list subscriptions at https://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com