ODB 1.75

Jim Creak jim at jacsoft.co.nz
Wed Apr 28 02:58:01 UTC 2021


We took this a step further, using #MU for the keyID field each ping would update a #FDT field.  That way we could then track which computes were still linked to the datafile if we ever needed to ask people to quit the program.

Thanks
Jim

JACSoft Programming Ltd. <http://www.jacsoft.co.nz/main.shtml>
> On 28/04/2021, at 2:34 am, Terence Young <terry.young at journeymhc.org> wrote:
> 
> HI,
> 
> I use the odb on linux.
> 
> Our connections would get dropped with inactivity.  The solution was to create a timer that does a simply query against the datafile periodically.
> 
> Actually, we do two connections...
> 1) we do a single file find on a table (PingTable) that has a sngle record with KeyId = 1
> 2) we use an omnis sql connection to get a count(*) of records from a table with a small amount of records.
> 
> The $timer method calls the $GetCount method built into an object class (oPingServerTimer)..
> ;  this returns today's date in a parameter sent as a field reference, the code returns kTrue if sussessful
> Begin reversible block
> Calculate #FDT as 'M/D/y H:M:S:s'
> End reversible block
> ;  check params
> If nam(pCount)='pCount'     ;; field reference is not set
>   Quit method kFalse
> End If
> 
> Clear selected files {PingTable}
> Single file find on PingTable.KeyId (Exact match) {1}
> ;  Sound bell
> Do $ctask.tvStatementOmnisObj.$clear() Returns lvRtnFlag
> Begin statement (Carriage return)
> Sta: {select count(*) from xaptApptType}
> End statement
> Do $ctask.tvStatementOmnisObj.$execdirect() Returns lvRtnFlag
> If lvRtnFlag=kTrue
>   Do $ctask.tvStatementOmnisObj.$fetchinto(pCount) Returns lvFetchStatus
>   If lvFetchStatus=kFetchError
>     Do tvProcCall.$SQLV3ErrorChk($cclass().$name,$cmethod().$name) Returns lvRtnFlag
>     Quit method kFalse
>   Else
>     Do $ctask.tvStatementOmnisObj.$clear() Returns lvRtnFlag
>     If pick(isnull(pCount),pCount,0)=0
>        Quit method kFalse
>     Else
>         Quit method kTrue
>     End If
>   End If
> Else
>   Do tvProcCall.$SQLV3ErrorChk($cclass().$name,$cmethod().$name) Returns lvRtnFlag
>   Quit method kFalse
> End If
> 
> Quit method kTrue
> 
> The $construct method for the timer object has the following code...
> 
> Do $cinst.$useseconds.$assign(kTrue)
> Do $cinst.$timervalue.$assign(60)
> Do $cinst.$autoreset.$assign(kTrue)
> Do $cinst.$starttimer()
> 
> The $timer method does the following..
> 
> ;  Restart the timer object if it is not $reentrant.
> If $cinst.$reentrant=kFalse
>   Do $cinst.$starttimer()
> Else
>    ;  No other methods are in the method stack.
>   ;  Run the timer object method initiated code.
>   If not(#EDATA)
>     ;  OK message  {not in edata [$cinst.$queueevent]}
>     Do method $GetCount (ivCount)
>   Else If #EDATA&($topwind().$name='wFast_Search')
>     Do method $GetCount (ivCount)
>   Else
>      ;  do nothing
>   End If
> End If
> Quit method kTrue
> 
> When connecting to our servers from a terminal using ssh, we use the following..
> 
>     ssh -o ServerAliveInterval=25 journey at elrond
> 
> I also create a persistent connection to the odb server and then tail the Messages file..
>   tail -F /usr/local/omnissoftware/omnisdatabridge1.73/messages.txt
> 
> This allows me to see who is connected and also the pings.
> 
> 
> 
> Terence J. Young, DC
> 
> System Administrator
> 
> IT
> 
> (608) 280-2679
> 
> ________________________________
> From: omnisdev-en <omnisdev-en-bounces at lists.omnis-dev.com <mailto:omnisdev-en-bounces at lists.omnis-dev.com>> on behalf of Juan Bofill <juanbofillaba at gmail.com <mailto:juanbofillaba at gmail.com>>
> Sent: Tuesday, April 27, 2021 7:59 AM
> To: OmnisDev List - English <omnisdev-en at lists.omnis-dev.com <mailto:omnisdev-en at lists.omnis-dev.com>>
> Subject: Re: ODB 1.75
> 
> CAUTION: This email originated from outside Journey. Please verify the sender before opening attachments or clicking links.
> 
> 
> It drops the connections. Tried with BigSur, High Sierra and El Capitan.
> 
> Thanks
> 
>> On Apr 27, 2021, at 8:53 AM, Thad Bogert <thad at technosolver.com> wrote:
>> 
>> Hi Juan,
>> 
>> Is there a firewall between the ODB and the clients?  Perhaps on the machine hosting the ODB?  Also are all machines connected via ethernet?
>> 
>> Does the ODB process disappear or does it just drop connections?
>> 
>> 
>> 
>> 
>>> On Apr 26, 2021, at 9:25 PM, Paul Mulroney <pmulroney at logicaldevelopments.com.au> wrote:
>>> 
>>> Hi Juan,
>>> 
>>> Is that 60 data files being hosted via ODB on the one server?  It might be a file handles issue.  You need to set the max file handles to a larger value.
>>> 
>>> Another thought - do you have a disconnection timeout set?
>>> 
>>> I seem to recall that "app nap" was a thing to look out for on the Mac.
>>> 
>>> This is stretching my brain cells because we moved to Postgres years ago.  Issues with ODB are in the distant past for us!
>>> 
>>> Regards,
>>> Paul.
>>> 
>>> 
>>>> On 26 Apr 2021, at 11:37 pm, Juan Bofill <juanbofillaba at gmail.com> wrote:
>>>> 
>>>> Hi all
>>>> 
>>>>    I have converted from Omnis 4.3.2.1 NON UNICODE to Omnis 10.2. I have over 60 data files converted in DML mode and the libraries are all working again in 10.2. It all looks ok up to this point!
>>>> 
>>>>    Now, before converting to SQL, I thought I would try ODB 1.75 and see if I could get away with it while finally converting to SQL. It started to work with record locking and all!!!
>>>> 
>>>>    After a while ODB 1.75 stops serving with apparent reason. Tried serving with Big Sur and High Sierra with same results.
>>>> 
>>>>    I know I should be on SQL but would like to know why it stops like that. Computer is set to never sleep as well as hard disks.
>>>> 
>>>>    Any help?
>>>> 
>>>> Thanks
>>>> 
>>>> Juan
>>>> _____________________________________________________________
>>>> Manage your list subscriptions at http://lists.omnis-dev.com
>>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com
>>>> 
>>> 
>>> 
>>> A man rushed into the doctor’s office and shouted, “Doctor! I think I’m shrinking!”
>>> The doctor calmly responded, “Now, settle down. You’ll just have to be a little patient.”
>>> --
>>> Paul W. Mulroney                                            We Don't Do Simple Pty Ltd
>>> pmulroney at logicaldevelopments.com.au       Trading as Logical Developments
>>> www.logicaldevelopments.com.au <http://www.logicaldevelopments.com.au/><http://www.logicaldevelopments.com.au <http://www.logicaldevelopments.com.au/>>                   ACN 161 009 374
>>> Ph: +61 8 9458 3889                                       86 Coolgardie Street
>>>                                                                       BENTLEY  WA  6102
>>> 
>>> _____________________________________________________________
>>> Manage your list subscriptions at http://lists.omnis-dev.com <http://lists.omnis-dev.com/>
>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com <mailto:omnisdev-en at lists.omnis-dev.com>
>> 
>> _____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com <http://lists.omnis-dev.com/>
>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com <mailto:omnisdev-en at lists.omnis-dev.com>
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com <http://lists.omnis-dev.com/>
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com <mailto:omnisdev-en at lists.omnis-dev.com>
> If you received this e-mail in error, please notify the sender, delete the e-mail, and do not use, disclose or store the information it contains. This e-mail and any attachments may contain confidential information, including records protected by WI Mental Health 51.30 and/or AODA federal confidentiality rules (42 CFR Part 2) – both prohibit you from making any further disclosure of this information unless further disclosure is expressly permitted by the written consent of the person to whom it pertains or as otherwise permitted by 51.30 or 42 CFR Part 2. A general authorization for the release of medical or other information is NOT sufficient for this purpose. Federal rules restrict any use of this information to criminally investigate or prosecute any alcohol or drug abuse client.
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com <http://lists.omnis-dev.com/>
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com <mailto:omnisdev-en at lists.omnis-dev.com>


More information about the omnisdev-en mailing list