AW: O$: SQLite, Table.$dowork() and sequence numbers

Rudolf Bargholz rudolf at bargholz.ch
Tue Jul 26 11:16:39 UTC 2022


Hi Martin,

the main reason many do this is to keep things local. You want your methods to perform independent units of work, that have no influence from outside, or affect outside state. This makes your code much more stable and comprehensible in the long run. Using global values, which is what #F is, means you **hope** no one outside of your method will change this state, and mess with your code flow. But global state becomes a dangerous thing after a certain level of complexity in your code. Using local variables as much as possible means you can test single methods independently of your general workflow. The use of vbOK below is just a small building block in this philosophy. Try structuring your code that the methods depend only on what you enter and will always return the same thing for the same input. Once the methods are working you can trust the code and go on to something else being sure nothing you do later will affect the code in that specific method.

Regards

Rudolf Bargholz

-----Ursprüngliche Nachricht-----
Von: omnisdev-en <omnisdev-en-bounces at lists.omnis-dev.com> Im Auftrag von Martin Obongita via omnisdev-en
Gesendet: Dienstag, 26. Juli 2022 10:58
An: Paul Mulroney via omnisdev-en <omnisdev-en at lists.omnis-dev.com>
Cc: Martin Obongita <martin.obongita at yahoo.com>
Betreff: Re: O$: SQLite, Table.$dowork() and sequence numbers

 Hi Paul,
Sorry, I don't wish to be rude, but could I interject and ask why you use vbOK variable instead of using the inbuild #F variable to return the status of a flag?
Kind regards, Martin.
    On Tuesday, July 26, 2022 at 06:18:36 AM GMT+3, Paul Mulroney via omnisdev-en <omnisdev-en at lists.omnis-dev.com> wrote:  
 
 Hi $All

We're investigating using SQLite for a demo version of our software.  We use sequence numbers which are automatically generated for unique record IDs. Currently we use Postgres, and in our $dowork() method of our Table superclass we have the following to generate the new sequence number for us automatically:

$dowork:
> Do $cinst.$sendall($cinst.$setNewIdent(),$ref.$status=kRowInserted)
> Do default Returns vbOK
> Quit method vbOK

and the $setNewIdent method:
> Set reference voStatement to $cinst.$statementobject Begin statement
> Sta: {SELECT 
> nextval('[$cinst.$servertablenames]_[isPrimaryKeyName]_seq')}    ;; 
> Postgres - eg SELECT nextval('fContract_seq_seq') End statement Get 
> statement vsQuery
> 
> Do voStatement.$prepare() Returns vbOK If vbOK
>     Do voStatement.$execute()
>     Do voStatement.$fetchinto($cinst.[isPrimaryKeyName])    ;; If this 
> is a row or a line in a list, return into this column Quit method vbOK

In SQLite, that doesn't exist.  Instead there's a RowID property, which is the equivalent of the sequence number.  The problem is, this is automatically generated AFTER the record is created, so we can't use the pre-emptive method that we use in Postgres.

My question is this:  is there a way to achieve the same in SQLite?    Is there a way we could add a "returning rowid" to the insert SQL command and then read that back into the table row/list instance?

Regards,
Paul.

"Debugging is like being the detective in a crime movie where you're also the murderer."
--
Paul W. Mulroney                                            We Don't Do Simple Pty Ltd pmulroney at logicaldevelopments.com.au      Trading as Logical Developments www.logicaldevelopments.com.au                  ACN 161 009 374
Ph: +61 8 9458 3889                                      86 Coolgardie Street
                                                                        BENTLEY  WA  6102

_____________________________________________________________
Manage your list subscriptions at https://lists.omnis-dev.com Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 
  
_____________________________________________________________
Manage your list subscriptions at https://lists.omnis-dev.com Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 


More information about the omnisdev-en mailing list