An app needs a "Setup the Database" routine correct ?

Sten-Erik Björling s-e.bjorling at
Thu Jan 25 01:31:06 EST 2018

Hi Das,

I do not use schema classes at all to represent tables in a database - I use the approach for dynamically create a unified table class template from the database model at the database itself presented by Dan Ridinger at a Euromnis event a number of years back. This to prevent having potential version conflicts later on. The resulting table class template from this operation is then used to create a row var template that will be copied during the code execution. Copying from a row var template is about three times faster than defining it from a schema class. This might not matter much for a fat client app but for apps running on an application server with hundreds and thousands of simultaneous users it matters a lot. Presented these approaches and some others in regard to session pools, SQL workers and push approaches using object centric approaches at the German conference 2017.

The experiences from this is quite interesting - the internal processes within Omnis app server itself are often aggregated within 0.2-0.5 milliseconds - the majority of the time consumed for delivering a request to the clients are used for the Postgres database operations and the most time demanding operation is the delivery of the results to the client across the internet.

I strongly recommend that you look into the approaches for session pools, SQL workers and even push early in the process of planning your application. And I recommend also to look into the overall structural architecture of your system to allow it to be modular not only in regard to data / information access but also in regard to the user interface functionalities.

Take care, all the best…



> 24 jan. 2018 kl. 23:31 skrev Phil (OmnisList) via omnisdev-en <omnisdev-en at>:
> Hi Das,
> Yep, like others, we do that, the installer creates a database and a default user...
> But then the Omnis code creates tables and columns from its own Schema structure.
> Any changes down the line in the schemas are also handled by the code, so modifications...
> Be careful of schema versions, if someone logs in with an old lib, you don't want the code to revert to an old schema definition, potentially losing columns (fields) of data.
> We store the database structure version within the database, so it knows if it can be updated.
> Joins, if your using tables for queries then check out the $fromclause...
> this is a good place for joins leaving the where clause to do its job...
> regards
> Phil Potter
> Based in Chester in the UK.

Sten-Erik Björling
Enviro Data
Kyrkogatan 5A 2 tr
SE-972 32  Luleå

E-Mail: s-e.bjorling at
Mobile: +46-70-655 11 72
Wire: @stenerikbjorling
Skype: stenerikbjorling
iChat: stene at
FaceTime: stene at
Hotmail / Messenger: stenerikbjorling at
GMail: stenerikbjorling at


This email and any files transmitted with it are confidential, may be legally privileged and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, please note that any use, distribution, or reproduction of the contents of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by return email and destroy all copies of the original message including any attachments thereto. Thank you.

Please note that we take reasonable precautions to prevent the transmission of viruses; however, we cannot guarantee that this email or its attachments are free from viruses. We only send and receive emails on the basis that we are not be liable for any loss or damage resulting from the opening of this message and/or attachments.

More information about the omnisdev-en mailing list