Cristina -
I?m sure our code, although altered somewhat, and the code I mentioned as being in the archives, was originally based on Doug?s code.
Thanks Doug.
__________________________
Gary Connor, Ph.D., CIO
DirectLine Technologies, Inc.
directline-tech.com
On Oct 6, 2014, at 9:32 AM, Doug Easterbrook <***@artsman.com> wrote:
> hi Christina (bruno), et al:
>
>
> I've posted a link to some auto expanding code we used for years in omnis 7 as well as an automatic data base . Feel free to use any part of it or adapt it to your own use
> https://www2.artsman.com/omnis/index.html
>
>
>
> Our 'best practices' approach was to try to avoid support, so we'd do this:
> - set up a database (empty and small on purpose) -- the .df1
> - immediately add one segment at full size -- the .df2
>
> and depending on potential growth, we might add .df2 etc.
>
>
>
> Omnis was always smart. It:
> -- adds new data to the fixed length segments, and
> -- only when there is no space left, will it put it into the initial auto expanding .df1 segment.
>
> thats probably because it looks for segments with free space, so we always made the first segment as small as possible. With nothing in it, it was always that way.
>
>
>
> that means... new data went into other segments. our auto expansion code asked the user when there was a certain amount of space free across all the .DFx files if they wanted a new segment and we'd make a new one at full size.
>
>
> that way we'd never hit out of space without at least some time to deal with it. And if we missed it at a client site for a day, then omnis would start auto-expanding the .df1 segment.
>
>
> it saved our bacon a number of times because you don't want to get the database full message.
>
>
>
> side note: we also built an automatic database copy tool --- and when that wrote to the new database, it put all the data into the fixed segments. Part of the recommendation, at that time, was to rebuild the database on some periodic basis to get omnis to make better use of the space, make the indexes contiguous and leave free space. it did make omnis go faster when the data inside the data files was contiguous and free space was allocated.
>
>
>
>
>
> Doug Easterbrook
> Arts Management Systems Ltd.
> mailto:***@artsman.com
> http://www.artsman.com
> Phone (403) 536-1205 Fax (403) 536-1210
>
> On Oct 6, 2014, at 10:00 AM, omnisdev-en-***@lists.omnis-dev.com wrote:
>
>> In addition to previous contributions, my two cents :
>>
>> - 1. Next time, as soon as the first segment has reached a size around 200 Mb or so (at some space below maximum 256 Mb = 524288 blocs) and you foresee it will still grow, add a new segment with a reasonable size to work smoothly for some time.
>> Save the new data size ($cdata.$disksize) in a constant of the data file,
>> and in Startup/0,
>> ; compare the present $disksize at startup with the saved one
>> If $data().$disksize>MySavedStartingSize ;; if data size has increased, it means the second segment is full and Omnis is starting to expand the only one it can: segment number 1. The datafile size has to be increased.
>> OK message : "Call Cristina soon ! Your datafile has to be extended." *
>> end if
>>
>> - 2. In case you have missed the situation 1:
>> After expanding your datafile by adding a new segment (that will not extend by himself), and to prevent your customer to be stuck with a alert message "Datafile is full" in the middle of his work :
>> In Startup/0 :
>> If $data().$freesize<=5000000 ;; check for less than five Mb free space
>> OK message : "Call Cristina soon ! Your datafile has to be extended." *
>> end if
>>
>> * Automatized datafile extension might be called here (ask for details if needed)
>>
>> HTH
>>
>> Bruno
>
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com