Re: High Volume Data over LAN/WAN/VPN etc...

You set the option on the copy of dbEngine that you are using.

The options are not permanent. If you want permanent values,
set the equivalent values in the registry.

It doesn't matter when you set the options: set before you
need them. Change them to whatever you want.

You need to set the options each time you use the dbengine
(unless you set the registry values).

Have you seen the demo version of Access on the Microsoft site?
Note that when MS wants to demonstrate Access for many users on
the internet, they use a Terminal Services session.

(david)




<cefrancke@xxxxxxxxx> wrote in message
news:1150752166.191245.262410@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks David,

I did some research and have found some references to the various
option values, based on your post in April this year.

I have a split database,


Do I set the option on the back end or front end?
Is the option permanent once it is set?
Should it be set at the start of the application? (All the tables are
being loaded here for my app)
Do I need to reset the setting back when the app is closed?
Do I need to set the options on every machine I deploy the app on?

Thanks for your consideration,

Christopher


david epsom dot com dot au wrote:
Yes, you can increase the size of the Jet cache, and
increase the time out interval so that stuff is not
invalidated out of the cache. Have a look at the dbengine
option settings.

(david)

<cefrancke@xxxxxxxxx> wrote in message
news:1150465446.204320.174110@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
In an effort to optimize and speed up applications.....
(I have a minimum 15,000 record (20+ fields) database, multi-user(<5)
over WAN)


In theory...

Is there a technique out there where high volume data is "uploaded" on
program start, from the back end file (split database) on a remote
machine (LAN/WAN/VPN etc...) to the front end local machine and update
the back end with changes when the front end closes?
(I'm aware that synchronizing changes with other users may be tricky.)

or

Some form of "Paging" the data in a data*** view in browsable chunks,
where as the user browses, the front end requests more data from the
back end (in small, yet speedy chuncks). (Users normally see all
records, (that is, the data*** "contains" all records) and "drill
down" from there.)

Any ideas or links are appreciated.

Christopher




.

Loading