split database in access

[jwb]

I have a partner in a small Access project, who I do not share a network
connection with.

I am maintaining the tables and data, and my partner is creating forms and
reports.

If I split the database, can I email her the ***.mdb file while keeping the
***be.mdb file on my computer.

My plan is that I would continue to populate the table with data, and then
when she emails me back the ***.mdb (I think you would call that the front
end) I over write the ***.mdb file that exist in my folder along with the
***be.mdb file and I would then be able to use her forms and reports with the
table that now has more data in it than when I sent her the ***.mdb file a
few days before.

I am admittedly new to this, and don't want to make this too complicated,
however I have a need to split the work on this project, and we are not on a
network connection but rather will move files back and form either via
emailing (I have figured out I have to change the extension to something
other than .mdb or outlook won't send it) or use a jump drive.

I am grateful for anyone's help.

 

[Albert D.Kallal]

What you want sounds good....

The above sounds like a good idea. However, the person also needs the
tables, else how would they test, debug, and try out the forms and code
written? So, yes, for most part, the above is correct, but the person would
also need a copy of the back end data so as to test the application. Of
course the whole idea of splitting was so that the developer can modify
forms, write new code, and even enter some test data with OUT ANY WORRY as
to damaging, or even touching your production database.

she receives it, opens it with access, works with the table to create forms
and reports etc, and then emails it back to me.

Well, you have to be careful. The above is not 100% right. The other user
can easily change forms, reports, write new code, fix bugs and errors etc.
Up to this, what you state above is 100% correct. However, the part about
modifying the tables is another issue. If the developer modifies the backend
part of the database, the you have deal with this issue. Anytime a new
table, or even a new field is added to the database, you do this on the BACK
END part. (you can't make these types of modifications from the front end
part).

So, to deal with the problem of the back end changes done by the
developer(s)..you can:

** Have the developer ask you to send them a copy of the backend database
for SHORT time, and they will make those modifications to the back end, and
then SEND IT BACK TO YOU. So, during this period of time when the back end
is being modified by the developer, you will NOT be able to enter data,
since your developer will now have your data part for modifications. Often,
this period of time can be quite short, since they likely finished all the
changes to the front end, and already know what changes they made to their
back end part. So, when they receive the actual BE data, they just make the
SAME modifications that they made to the test BE. They then send both the
FE, and the BE back to you.

** If you don't want to do the above, then you can have the developer SEND
you a list of modifications that you must make to your production back end.
So, when they send you the NEXT GREAT version of the front end part, they
will also have to inform you of the changes made to the back end. This is
only practical if the end user has access abilities.

** If the developer is good, often, they will simply write some code that
makes the modifications to the back end for you. This way, they just send
you the new front end...it will detect that certain fields or even tables
are missing, and modify the back end (or create the tables in the back end).
This is more difficult then the above two steps, since code to modify the
tables must be written, and that is certainly more time consuming then just
modifying the back end table with the table design view. However, for wide
spread commercial applications that I deploy to my users, I can't have them
send me the back end, and I don't want to be bothered with MANY people
having to send me their data (which, often is private data that companies do
NOT want to part with). Hence, I often write code to make the changes for
me. This is more time consuming (expensive), but well worth it if you have
many clients running the software. In fact, the users don't have to do
anything (even be aware of table modifications, or even if new tables are
added...since my code does this. This approach is the best..but is also the
most expensive solution).

 

[Neil]

Yes, you have the general idea. What I would do in your situation is the
following:

1. Send your partner your ***.mdb file, along with ***_be.mdb which has some
data in it so that they can test their reports, forms, etc.

2. When your partner has finished developing the front end (***.mdb) they
can then E-mail it back to you to use with your fuly populated data tables.
They do not need to mail you ***_be.mdb as this is only data that has now
been added to by yourself.

3. Both you and your partner will have to use the linked table manager to
re-connect your tables to your front end after after each E-mailing
operation, but that should be fairly easy for you.

HTH

Neil
www.nwarwick.co.uk

 

[Klatuu]

In addtion to the other good advice you have received, be aware that you and
your partner will have to deal with linking issues. You will either need to
set up identical directory structures, use the Linked Table Manager when you
send mdbs back and forth, or have the person doing the development write a
relink routine.