VCS Database Timeout

Wed Jun 24 10:26:38 EDT 2020

hi Phil.

Mostly our own history.   We stayed at Studio 5 for a long time.   There was no features that studio 6 offered.    Studio 8 was the first that was MacOS Cocoa — and thats where we began conversion efforts and 8.1.6, by all accounts was the first that epopel voted on as being good.

We needed to have one code base, so we wrote a bunch of conditional code in studio 5 to take care of Studip 5 to 8 differences.       Then came 10 and 10.1 and OW3 workers … all really great and we use them.

30% user base still had windows 7 machines and a bunch of had 32 bit only.       so we a 2.5 year long ‘conversion’ process with warnings of ’64 bit is coming, 64 bit is coming’ .

it was that need to be in two camps that keep us code writing in studio 5 (hence the VCS) and always migrating the finished code to Studip 8, 10 or 10.1 for deployment only.   Throughout this two year period, we were doing JSON exports with every version of Theatre Manager we released and updating a separate git repository — but we never built from it.

Jun 8th (this year) was our deadline for 64 bit only and we had managed to get all but two users off 32 bit and that was the date that we stopped building in 32 bit.

so, now that we are only in Studio 10.1, the VCS is only a stop gap because we know it.  I’m running JOSN exports for every VCS commit to be absolutely sure that its working (it its).   We know others are using this successfully.

and now that we can be fully committed, we will be working on automatic scripted builds and creation of deployments (standalone installers and linux docker containers) in the coming months.

Its bee na long time coming - I’m glad we are here.  GIT is our choice for the future as we have hundreds of repositories already. omnis was on the only one that was not.    and mostly a matter of timing, studio features and our user environment that we didn’t get there sooner.

hope that helps.

Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug at artsman.com
http://www.artsman.com
Phone (403) 650-1978

> On June 24, 2020, at 1:18 AM, Phil (OmnisList) via omnisdev-en <omnisdev-en at lists.omnis-dev.com> wrote:
> 
> Just a query Doug,
> 
> Why 10.1 why not 817 or 10, JSON export was there also?
> 
> regards
> Phil Potter
> Based in Chester in the UK.
> 
> On 24/06/2020 00:35, Doug Easterbrook wrote:
>> hi there.
>> 
>> this is a *feature* of the omnis VCS.
>> 
>> if your database connections drops for any reason, the VCS has not been made smart enough to reconnect.   It assumes a permanent connection at all times.
>> 
>> We use postgres for our VCS that is some 2000 miles away in our cloud servers — over a VPN.
>> 
>> if the internet hiccups or the VPN drops, we will see this exact behaviour.
>> 
>> 
>> does it happen all the time?   no, it is somewhat infrequent.        it seems to happen when you don’t want it to and you have to hit ok to a bunch of messages, close the VCS session and re-establish it.
>> 
>> 
>> hope that helps.
>> 
>> 
>> 
>> and.. as a final note,  we’ve been using the VCS for about 15 years, since Studio 4 days and wouldn’t go without using it.     We are just about ready to transition out of it with Studio 10.1 and go with GIT.     The JSON export and pushing to a git repository has a number of advantages:
>> 
>> - a far better resilience to disconnections (ie doesn't’ really impact you)
>> - a more modern workflow — which means the ability to make changes to code with out checking it out and then just pushing the changes to your main git repository
>> - the ability to do branches, code compares, blame (see who actually made the last change to a specific line of code in any method)
>> - you can integrate git with workflow and build services like Jenkins or gitlab
>> 
>> 
>> if you are studio 10.1 — I’d consider git as an option.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Doug Easterbrook
>> Arts Management Systems Ltd.
>> mailto:doug at artsman.com
>> http://www.artsman.com
>> Phone (403) 650-1978
>> 
>>> On June 23, 2020, at 11:06 AM, Jeff Gibson <jgibson at interceptsolutions.com> wrote:
>>> 
>>> So I have created a MySQL database running on Hostgator that we are using to
>>> start testing VCS Source Control.
>>> 
>>> 
>>> 
>>> We fully intend on using this as a sandbox for now.  So if we break
>>> anything, we can blow the database away and start over.
>>> 
>>> 
>>> 
>>> Anyway, I've managed to successfully push our source code up into our MySQL
>>> database running on Hostgator.
>>> 
>>> 
>>> 
>>> Everything connects with no issues.  Still trying to work my way around
>>> learning how this VCS environment works in conjunction with the library
>>> file.
>>> 
>>> 
>>> 
>>> After about 10 or 15 minutes, I start getting the following messages.
>>> 
>>> 
>>> 
>>> SQL Error - kStatementNotPrepared - The statement must be prepared.   Lost
>>> connection to MySQL server during query
>>> 
>>> 
>>> 
>>> Followed by
>>> 
>>> 
>>> 
>>> SQL Error - kStatementNotPrepared - The statement must be prepared.   MySQL
>>> server has gone away (this displays 6 times)
>>> 
>>> 
>>> 
>>> This obviously feels like some kind of timeout issue.  Where we're losing
>>> our connection to the VCS database.
>>> 
>>> 
>>> 
>>> I have found the following settings in the VCS_SESSION object.
>>> 
>>> 
>>> 
>>> On the Advanced Tab
>>> 
>>> $logontimeout  (set to 15)  I don't know if that's seconds or minutes.  I'll
>>> assume minutes.
>>> 
>>> 
>>> 
>>> On the MySQL Tab
>>> 
>>> kMySqlOptConnectTimeout
>>> 
>>> kMySqlOptReadTimeout
>>> 
>>> kMySqlOptWriteTimeout
>>> 
>>> 
>>> 
>>> Any suggestions on what can be done to turn off the Timeout option all
>>> together?
>>> 
>>> 
>>> 
>>> Thanks!
>>> 
>>> 
>>> 
>>> Jeff Gibson
>>> 
>>> Oversite Online
>>> 
>>> Nashville, TN
>>> 
>>> _____________________________________________________________
>>> Manage your list subscriptions at http://lists.omnis-dev.com
>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
>> 
>> _____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com
>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com