Locking

[Phil]

Bas, Wendy,

Actually, I don't really agree with that as an issue.

We have routines on startup check the schemas in our application, 
against, in our case, a postgresql server, and update the server if 
there are any required changes...

Takes little noticeable time to achieve, and once I add a field in a 
schema, I just restart my dev app, and it is from then on in the data 
structure.

The reality is I don't create tables anymore, I just create a schema, 
and set the userinfo field to Create, then the code just creates the 
tables and primary key on startup...

For a brand new installation, my installer installs PostGreSQL, and I 
have it run a script to create an empty database, and a default user.

After that the program creates the tables, primary keys and any relevant 
defaults as required.

Any library updates, including schemas updates or new schemas, are 
looked after in the local data by the application...

So, unless there is something else, I don't see this as an issue?

regards
Phil.


On 12/12/2016 22:03, Bastiaan Olij wrote:
> Wendy,
>
> It's probably already mentioned in replies I haven't read yet but this
> really is a preconception that belongs in the past.
>
> Yes if you install the likes of Oracle on a server you'll need some clue
> people at your clients.
>
> Both MS SQL server and Postgres installed on a server are in 99% of the
> cases next->next->next installs after which you can forget the thing
> runs, it really is no more difficult than installing an ODB
>
> SQLLite and some special single exec deploys of Postgres are even simple
> 'drop in installs', there is actually absolutely 0 difference between
> installing a DF1 based Omnis application and deploying an SQLLite Omnis
> application, neither require a server install and use file sharing and
> file locking though the real beauty of SQLLite is that you can deploy an
> SQLLite solution to your small customers and switch to the likes of
> Postgres for your larger customers with limited effort.
>
> Finally one thing we've started doing is simply hosting Postgres servers
> 'in the cloud'. It's used by both small clients who do not have the IT
> support to look after their own machines and larger clients who like the
> inconvenience of being able to access their system from multiple locations.
>
> Your second remark however is one that I do fully agree with you is a
> weakness in Omnis, its the topic of one of my Omnis sessions and
> something I hope to find time in the short term to do something about.
> We've build a solution for our product for this and its something I've
> been itching to redo in a form that can be shared with the community.
>
> Cheers,
>
> Bas
>
> On 13/12/2016 2:52 AM, wendy wrote:
>> I think this really depends on your customer base - most of my customers now
>> have no more than 6 users and do not have IT experience to be able to
>> maintain a SQL database.
>>
>> Also being able to make changes to the database structure is extremely
>> simple with an Omnis database - a new version of the software and possibly a
>> check data - while SQL would mean scripts for them to run.
>

-- 

P G Potter, 11 Regency Court, Mickle Trafford, Chester, UK.

This message is confidential and intended for the use only of the person 
to whom it is addressed. If you are not the intended recipient you are 
strictly prohibited from reading, disseminating, copying, printing, 
re-transmitting or using this message or its contents in any way. 
Opinions, conclusions and other information expressed in this message 
are not given or authorised by the Company unless otherwise indicated by 
an authorised representative independent of this message. The Company 
does not accept liability for any data corruption, interception or 
amendment to any e-mail or the consequences thereof. Emails addressed to 
individuals may not necessarily be read by that person unless they are 
in the office.