Using Referances on access

  • Thread starter Thread starter Oded Kovach
  • Start date Start date
O

Oded Kovach

Hello there

I have huge access database that has reached to the limit of using moduls on
it.

Now i would like to split my application for many mdb/mde.

As i heared i need referances for this. How can i use them and what is the
technic for using it?

any help would be useful
 
My understanding from your post is that you want to split a single database
file into a front end file and a back end file. Assuming this, if you have
all references properly set in the current file, you should not need to do
anything else when you split the file.

Use the Autosplitter wizard in ACCESS to split the current file into a back
end and front end. Then put the back end file on a shared folder where all
users can get to it (they'll need create/read/write/delete access to that
shared folder), and give all users a copy of the front end file.
 
Oded said:
Hello there

I have huge access database that has reached to the limit of using moduls on
it.

Now i would like to split my application for many mdb/mde.

As i heared i need referances for this. How can i use them and what is the
technic for using it?
Click to expand...

I have never fully applied this, only been playing. From my experience
with A97, you need to
* open any code module
* choose menu Tools->References
* click Browse
* change the type to MS Access Databases
* point to your library database

You have to have a 'library' ready, one with as much code as is not
needed in a form or report: the more general routines.

My question as why and how you have so many forms is still open!
 
Whell Ken.
The split that you are talking about is already exist on my application

In fact the database is on sql server.

The split i ment is to split the application for many mdb. or mde

Do you know this kind of split and tell give me an idea how to use it?

This is way i tought:
1. creating the master mde that will provide: connect properties, main
forms that will always be used
2. Other forms/ reports ect... moving to secondery mde's according to
subjects and create referance for them from the master MDE.
3. On the secondery MDE create module that open each object and call it
from the master MDE.
4. In order to return to the master MDE create on the master and on each
secondery MDE a tree form that open each object on the current MDE

What do you thing about this?
 
What you're saying is that the front end database file is what you want to
split? Is your current front end file at or near 2 GB in size? That is the
upper limit for size of an .mdb or .mde file.

Can you give a few more details about "modules" as you mean them? A module
has no specific limit that I know about, but a procedure within a module (a
subroutine or a function) does have a limit. You can have multiple
procedures within a module.
 
Thankes Ken for your attanction

The limit is: 1024 moduls on the system. The reason i reach to this huge
amout of moduls it because i have almost 700 forms and 400 reports and most
of them are have module.

I also thinking of splitting my application to make it less complex. Can you
help me on it?
 
Oded said:
Thankes Ken for your attanction

The limit is: 1024 moduls on the system. The reason i reach to this huge
amout of moduls it because i have almost 700 forms and 400 reports and most
of them are have module.

I also thinking of splitting my application to make it less complex. Can you
help me on it?
Click to expand...
You're invited to mail me, I don't have 40 hours per week for your
project but I'd be glad to help. I feel little value in doing that on
the forum, though.
 
This can be started by you if you just make copies of the existing front end
database, and begin deleting forms and reports from it that will be in a
different copy of the front end. This "splits" the objects among different
databases.

However, the "trickier" part then is to tie all the front end databases
together via a new front end that will have to open the appropriate front
end for the feature selected by the user, and then to close that front end
and return to the initial front end when that feature is done. I don't know
of a wizard or built-in method for doing this. This probably will require
you to hire a professional developer or to go through a major learning curve
to figure out how to do it.
--

Ken Snell
<MS ACCESS MVP>
 
Back
Top