I'd say this approach is fine as long as you are very explicit about
opening and closing. You could have DmOpenDatabase() and MemHandleLock()
in AppStart(). MemHandleUnlock() and DmCloseDatabase() would be at
AppStop(). Then you are sure this databases is closed no matter how the
application exits.
I need to know more about your application to suggest further approaches.
Steve
Scott Gruby wrote:
> I'm working on an application that uses a large static database which
> is broken down into 6 records each about 60K in size. I access this
> database pretty regularly and was initially doing a DmQueryRecord
> then MemHandleLock, do stuff, then MemHandleUnlock to access the
> data. I then switched to doing the DmQueryRecord at startup and
> keeping the handle around as a global. This yielded a nice speed
> boost, but then I tried doing the MemHandleLock at app startup on the
> 6 records and keeping the pointers around (and then doing a
> MemHandleUnlock on app stop) and saw an even bigger speed increase.
>
> So my question is...is there a major problem with locking the handle
> at app startup and then unlocking it at app stop? Since I'm doing the
> locking early in the app's life, I don't think that memory
> fragmentation is a problem here.
>
> (I really dislike this approach, but the speed increase is
> significant and I need to squeeze all the performance that I can out
> of this application.)
>
> --
> Scott Gruby
> <http://www.gruby.com/>
