Conversion of an MS Access application

[Oldie]

I have built an MS Access Application under MS Office XP (but I also
own MS Office 2000). I have split the application in the pure database
tables and all the queries, forms, reports and macro's.

Now i want to use this application for different foundations in the
Netherlands but I want to secure my application so no one can change
it, copy it or steal it from me. I always thought there was a kind of
conversion tool that would translate the whole application into an EXE
program. But I understood from the different discussions that I have to
translate my MDB's to MDE's and add an Access run program to it. In
this case I can in no way prevent people from stealing my database
concept with all the tables and relations neither can I prevent them to
copy things. Is there a better solution available somewhere and what
does it cost?

I am a very experienced computer user (since 1958) and PC user and
consider myself as a database expert!

Eagerly looking forward to any solutions

[Tom van Stiphout]

On 25 Feb 2006 12:09:11 -0800, "Oldie" <ke*@hiquad.demon.nl> wrote:

Then you should know there is no such thing as perfect security.

MDE protects against stealing your code: only the compiled version is
there, and your app is probably not THAT important that someone would
bother decompiling it.

One option is to use Access security. Download, study, and fully
understand the Access Security FAQ from microsoft.com before
proceeding. Again as an expert you already know all of this, plus you
know that this security can be broken by any number of password
crackers available on the Internet.

Another option is to protect your app with a dongle: a hardware key
that goes in the serial, parallel or USB port, and if not found by
your code, your app won't run. I've used products from aladdin.com and
they were straightforward to work with.

The database design cannot be protected given what I said about Access
security. Consider it your gift to the world :-) or consider another
database platform with higher levels of security available, such as
SQL Server 2005 Express Edition.

-Tom.

I have built an MS Access Application under MS Office XP (but I also
own MS Office 2000). I have split the application in the pure database
tables and all the queries, forms, reports and macro's.

Now i want to use this application for different foundations in the
Netherlands but I want to secure my application so no one can change
it, copy it or steal it from me. I always thought there was a kind of
conversion tool that would translate the whole application into an EXE
program. But I understood from the different discussions that I have to
translate my MDB's to MDE's and add an Access run program to it. In
this case I can in no way prevent people from stealing my database
concept with all the tables and relations neither can I prevent them to
copy things. Is there a better solution available somewhere and what
does it cost?

I am a very experienced computer user (since 1958) and PC user and
consider myself as a database expert!

Eagerly looking forward to any solutions

[Albert D. Kallal]

You most certainly can, and should hide all of the ms-access interface. The
options to complete hide and keep people out of the ms-access interface can
easily be done using the tools->start-up options. Using those options allows
you to complete hide the ms-access interface (tool bars, database window
etc). Also, using these options means you
do not have to bother setting up security.

Try downloading and running the 3rd example at my following web site that
shows a hidden ms-access interface, and NO CODE is required to do
this....but just some settings in the start-up.

Check out:

http://www.members.shaw.ca/AlbertKal...s/DownLoad.htm

After you try the application, you can exit, and then re-load the
application, but hold down the shift key to by-pass the start-up options. If
want, you can even disable the shift key by pass. I have a sample mdb file
that will let you "set" the shift key bypass on any application you want.
You can get this at:
http://www.members.shaw.ca/AlbertKal.../msaccess.html

The only additional things you really need to do to the above sample would
be to convert it to a mde...

I also have some screen shots..and some ideas as to how I use custom menu
bars in ms-access here:

http://www.members.shaw.ca/AlbertKal...erFriendly.htm
Also, I might as well give some ideas as to how one develops once you setup
the startup options...

Of course, during development, you will hold down the shift key so your
startup settings don't run. You then develop for awhile, and then to test in
"user" mode, you exit..and then re-enter the application without the shift
key bypassed. You will likely do this dance all day long as you run/test as
user mode, and then flip back in to developer mode (shift key used..so you
don't get the main custom menu). So, you can't develop, or really modify
things when you run your application with the startup settings...so you must
shift-by-pass them when you want to work.

And, in fact, I use alt-f4 to exit the application...the mdb file should
still be highlighted in the windows explore..so, then you hit enter key
(and, hold down shift key if you need be). This key stroke sequence and
exiting and re-entering the application will occur CONSTANTLY all day long
when you are developing.

When you finally have things just right...you create the mde
you plan to distribute...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[Albert D. Kallal]

>I always thought there was a kind of

conversion tool that would translate the whole application into an EXE
program.

no, you do have a essentially the same concept here, as a mde is your
executable. You can purchase a developers edition of ms-access, and thus
deploy your mde file to machines that don't have ms-access installed. Be
aware, that this runtime system is in effect a full ms-access install, but
with just the design abilities removed (so, this is a large install). I
can't really think of any software that works with a database that is a
simple .exe file these days anyway (That kind of went out with the slide
rule....).

The ms-access runtime for a2000 was a 150 megs in size (not the best for
downloading over the web for example). However, the a2003 runtime is a more
manageable 33 megs in size.
http://support.microsoft.com/default...b;en-us;842004

http://msdn.microsoft.com/library/de...sofruntime.asp
http://support.microsoft.com/default...b;en-us;842004
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[Lyle Fairfield]

Albert D. Kallal wrote:

You most certainly can, and should hide all of the ms-access interface. The
options to complete hide and keep people out of the ms-access interface can
easily be done using the tools->start-up options. Using those options allows
you to complete hide the ms-access interface (tool bars, database window
etc). Also, using these options means you do not have to bother setting up security.

I would very much like to hear the opinions of those who are more
familiar with Access Security than I about this statement, "using these
options means you do not have to bother setting up security".

[Larry Linson]

"Lyle Fairfield" <ly***********@aim.com> wrote

I would very much like to hear the opinions of
those who are more familiar with Access Security
than I about this statement, "using these options
means you do not have to bother setting up security".

I view the Startup Options as being more for keeping casual users from
stumbling over their own keystrokes and inadvertently causing problems. They
certainly won't keep a serious, experienced Access hacker from stealing your
objects or code or the user's data.

On the other hand, neither will Access security prevent someone to whom your
data or application is worth approximately US$150. That's a price for which
they can buy one of several "password recovery software" packages.

Because of this, I don't worry much about the security of the application
and code (I don't create database applications for "general distribution",
except examples that I purposely leave "open"), and typically rely on the
security of the server DB back end to secure the data. Fortunately, most of
my clients have had an honest workforce whom they trusted and no one else
had access to the DBs.

Larry Linson
Microsoft Access MVP

[(PeteCresswell)]

Per Albert D. Kallal:

that this runtime system is in effect a full ms-access install, but
with just the design abilities removed (so, this is a large install)

When running under a .MDE, can the user change page setup specs on reports?
If so, do the specs persist?
--
PeteCresswell

[Oldie]

As one Dutchman to an other: thanks very much! Yes I know all these
things, but I am quite sure that there has been (in the days of Access
2 or 5) a real compiler!
I wondered if MS has given this up or if there are new tools under
Visual Studio that I don't know.I have no knowledge at all of Visual
Studio.

[Oldie]

Thanks very much for your good support! I have immediately addopted
your Shift Enable/Disable key utility.
The problem is that i have the database on my own network but I am not
working anymore (being nearly 68). There are at least 4 or 5 companies
(foundations) that want to use my database program for their end-users
on private isolated PC's at home. There is not much I can do to make
them memeber and things like that. It will be to complicated to
distribute it this way.. But disabling the shift key and hiding the
Access toolbars is at least a good start.
Thanks very much for your ideas.
But I am sure there was a compiler in the days of Access 2 or 5. Maybe
it is in Visual Studio (I don't know this package).
I just want to help these foundations with just spending my time and
not my money!

[Oldie]

Thanks for your answer. I am from the time of the slide ruler and
studied math. But I am sure this tool was still there in Access 2
and/or 5.
My "clients" are volunteers helping f.i. heart and kidney foundations
to raise money. They work on their private PC's at home and in most
cases they don't have Access installed on their machines.

[Oldie]

I agree with your comment. You can setup security on your own PC or in
a business network. But I have to send my application to individual
volunteers who work at their private PC's and in most cases have not
even installed Access. I am looking for a solution to overcome this and
my problem is surely not a simple security problem on my PC

[Rick Brandt]

Oldie wrote:

As one Dutchman to an other: thanks very much! Yes I know all these
things, but I am quite sure that there has been (in the days of Access
2 or 5) a real compiler!
Nope. VB yes. Access No.
I wondered if MS has given this up or if there are new tools under
Visual Studio that I don't know.I have no knowledge at all of Visual
Studio.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Oldie]

Just one more question to my earlier comment.

Is there a possibility to rid any toolbar in Access given the fact that
it has to run on PC's at various places so I can't use the possibility
of using preferences!

I have used the switch-board with friendly buttons and users should not
see any other toolbar overhead!

Nice examples you showed by the way, but I have to keep it sober
because with two minor changes I want to change my application from one
company to another with name changes and logo changes.

[(PeteCresswell)]

Per Oldie:

Is there a possibility to rid any toolbar in Access given the fact that
it has to run on PC's at various places so I can't use the possibility
of using preferences!

Here's something to give the flavor of it. There are probably many
more options than the ones I am setting.
----------------------------------------------------------------------
Public Sub DeveloperMenusToggle(ByVal theVisibilitySwitch As Boolean)
1000 debugStackPush mModuleName & ": cmdShowDeveloperMenus_Click"
1001 On Error GoTo cmdShowDeveloperMenus_Click_err

' PURPOSE: To give/remove user access to the various things used by
' developer - like DB window, F11, Immediate, Code...and so-forth
' ACCEPTS: Visibility switch: True=Show, False=Hide

1003 Dim myToolBarSwitch As Long

1010 If theVisibilitySwitch = True Then
1011 myToolBarSwitch = acToolbarYes
1012 Application.SetOption "Key Assignment Macro", "AutoKeys"
1013 Else
1014 myToolBarSwitch = acToolbarNo
1015 Application.SetOption "Key Assignment Macro", ""
1019 End If

1020 With DoCmd
1021 .ShowToolbar "Database", myToolBarSwitch
1022 .ShowToolbar "Form View", myToolBarSwitch
1023 .ShowToolbar "Query Design", myToolBarSwitch
1024 .ShowToolbar "Formatting (form/report)", myToolBarSwitch
1029 End With

1991 With CurrentDb 'Restore various options
1992 .Properties("AllowFullMenus") = theVisibilitySwitch
1993 .Properties("AllowSpecialKeys") = theVisibilitySwitch
1994 .Properties("AllowBuiltinToolbars") = theVisibilitySwitch
1999 End With

cmdShowDeveloperMenus_Click_xit:
DebugStackPop
On Error Resume Next
Exit Sub

cmdShowDeveloperMenus_Click_err:
BugAlert True, ""
Resume cmdShowDeveloperMenus_Click_xit
End Sub
------------------------------------------------------------------------
--
PeteCresswell

[Oldie]

Thanks very much. Now i am getting somewhere (still have to try it
though).
But with MDE and Shift key disabled and no toolbars I think I am as
save as I want to be.

But I am affraid i still need a solution for my many users that do not
have Access on their machines

[HK]

There is indeed a developer's version of Access available. Office XP
Developer is what it was called in 2002. For the 2003 version, I think
you have to buy something called a Developer's Toolkit, though I didn't
have a lot of luck finding out much about it.

This won't give you an .exe file as was already mentioned, but it will
be a stand-alone file.

Visual Foxpro is still a development tool that allows you to compile
into .exe's. But there is no way to migrate your application from
Access to Foxpro.

[Jeremy Wallace]

I'm pretty sure, along with the rest of this group, who represent a
good portion of the most respected regular posters to this newsgroup,
that you are mistaken in your memory of this tool.

However, there is a way for your users to get Access quite cheaply.
TechSoup.org sells full versions of Microsoft Office, including Access,
for $20 to non-profit agencies. I would guess that most organizations
you are working for would be willing to pay the $20 per seat fee. Just
make sure you point out to them that the agencies can only make one
purchase per year, so they have to be willing to look at least a year
ahead when making purchasing decisions.

Jeremy
--
Jeremy Wallace
http://metrix.fcny.org

[Lyle Fairfield]

Oldie wrote:

Thanks for your answer. I am from the time of the slide ruler and
studied math. But I am sure this tool was still there in Access 2
and/or 5.

Of course it was. I remember discussing it with Jane Fonda during one
of our dates in the 1990's (when she wasn't all over me!).
Or was that Kim Novak? ... maybe Raquel Welch?

[David W. Fenton]

"Oldie" <ke*@hiquad.demon.nl> wrote in
news:11**********************@j33g2000cwa.googlegr oups.com:

But I am sure there was a compiler in the days of Access 2 or 5.

There's no such thing as Access 5.

Access 2 had the Access Developer's Toolkit, but that was replaced
by the Office Development Tools with Office 95, because it was in
Office 95 that all the Office applications got VBA built in (except
for Outlook), and so that it made sense to have a cross-suite
development tool. Access dropped Access Basic in favor of VBA, which
wasn't a huge switch, really.

The ADT for Access 2 was basically just a tookit for producing an
Access Runtime installation. All versions of Access have been
packaged this way. There was never any "compiler" for Access
applcations, as it would make no sense, since an Access app cannot
run except inside of Access the application.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Oldie" <ke*@hiquad.demon.nl> wrote in
news:11**********************@i39g2000cwa.googlegr oups.com:

I am from the time of the slide ruler and
studied math. But I am sure this tool was still there in Access 2
and/or 5.

I've answered this elsewhere.

There is no such thing as Access 5.

Access 2 had the Access Developer's Toolkit, which was basically
just the tools needed to produce a runtime distribution. There was
never anything that would produce an executable for an Access app,
only a way of distributing the runtime. This remains consistent to
this day, though MS has made many changes in the configuration of
tools you have to buy to get the tools to create a runtime
distribution.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Oldie]

I tried to put your module into my application but so far not
succesful.
Where should I install it and how do I start it?

[Oldie]

Not really funny!

[Oldie]

The application I built is for foundations that raise money by
door-to-door collections. The user are volunteering and work on their
own PC's. Could they all get a nearly free copy of Access? I don't
think so and one copy for all does not work.

Thanks anyway for your support

[(PeteCresswell)]

Per Oldie:

I tried to put your module into my application but so far not
succesful.
Where should I install it and how do I start it?

Have you written VBA code before?
--
PeteCresswell

[David W. Fenton]

"Oldie" <ke*@hiquad.demon.nl> wrote in
news:11**********************@p10g2000cwp.googlegr oups.com:

The application I built is for foundations that raise money by
door-to-door collections. The user are volunteering and work on
their own PC's. Could they all get a nearly free copy of Access?
I don't think so and one copy for all does not work.

Yes, all you need to do is get the Access Developer Tools
appropriate to the version of Access you're using and create a
runtime application.

This is exactly how it was done in Access 2, with the Access
Developer's Toolkit.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Albert D. Kallal]

"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:11*********************@z34g2000cwc.googlegro ups.com...

Albert D. Kallal wrote:

You most certainly can, and should hide all of the ms-access interface.
The
options to complete hide and keep people out of the ms-access interface
can
easily be done using the tools->start-up options. Using those options
allows
you to complete hide the ms-access interface (tool bars, database window
etc). Also, using these options means you do not have to bother setting
up security.

I would very much like to hear the opinions of those who are more
familiar with Access Security than I about this statement, "using these
options means you do not have to bother setting up security".

Well, actually, the problem is that MANY people confuse the security options
in ms-access and use them to try and hide ms-access features, or hide the VB
code, or hide the ms-access interface (security will not really do this for
you). This is not at all what the security is for.

Just like in sql server, you not going to use the security features of sql
server to hide the VB code, or the application code. They are TWO SEPARATE
concepts, and need to be kept separate in practice, and in peoples minds
also!!

.. You use ms-access security to prevent certain users from having access to
certain forms, and certain reports and tables. However, you do not need any
such security to prevent users from modifying code, or modifying reports, or
modifying forms.

If you create a mde, and disable the shift key, you well secured your
application form users messing with forms, or reports. If you need to
control WHO can use a particular form, then that is when security makes
sense (note carefully that in this case, we would STILL distribute a mde..as
that is our compiled application). So, keeping users out of code and design
of forms is very much a different problem then user-level security. (ULS
happens to have abilities to prevent users from seeing code, or design of
forms,but any respecting developer will deploy there application as compiled
code (mde) anyway....

As for keeping users out of actually seeing the tables, well, ok...you can
kind of do that too with ULS, but the results are not much better then just
hiding the ms-access interface, and deploying a mde to your users anyway...

I have many applications with ULS, but that changes little about the fact of
distributing a mde in these cases....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[Albert D. Kallal]

"(PeteCresswell)" <[e-mail]> wrote in message
news:lu********************************@4ax.com...

Per Albert D. Kallal:

that this runtime system is in effect a full ms-access install, but
with just the design abilities removed (so, this is a large install)

When running under a .MDE, can the user change page setup specs on
reports?
If so, do the specs persist?
--

Your page layout, margins, landscape etc. do persist with EACH report. If
you lay them out..they should not disappear.

However, you can use the file->page setup..and change the settings for the
printout....they will not be saved. So, they persist, but they are
changeable (hopefully, you done your work and the user(s) should have NO
reason to change the page layout options). However, if you expose the page
setup dialog.....or the printer dialog...users can change the margins
etc....
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[Oldie]

Thanks very much. This is what I thought, but I was not sure this was
still existing for later versions.
So this is the toolkit that must be part of Visual Studio now

[Oldie]

Have you written VBA code before?
--
PeteCresswell

Yes I have written professional programs in nearly every language.
And I have used VBA in Acces via the forms or reports!
But I have no experience implementing an independent module in Acces
and I don't know how to start this module at the start of my
switchboard!

[Lyle Fairfield]

Really Funny!

[(PeteCresswell)]

Per Oldie:

But I have no experience implementing an independent module in Acces
and I don't know how to start this module at the start of my
switchboard!

There are a couple of ways:

1) In Tools|Startup you can specify a form tb opened when the app starts.

2) You can create a macro named AutoExec and it will be executed when
the app starts.
I prefer #2 because it brings everything up to the surface where somebody
can see it rather than burying the functionality in an option setting.
I emailed you a working example. You'll have to dig through it a little
to figure out what all is going on - and it's definitely not perfect -
but should help illustrate what needs tb done.

--
PeteCresswell

[David W. Fenton]

"Albert D. Kallal" <ka****@msn.com> wrote in
news:bHUMf.78499$B94.2960@pd7tw3no:

Well, actually, the problem is that MANY people confuse the
security options in ms-access and use them to try and hide
ms-access features, or hide the VB code, or hide the ms-access
interface (security will not really do this for you). This is not
at all what the security is for.

I beg to differ. It's a perfectly valid approach for securing your
application design, because the application design is stored in Jet
tables, so Jet security works just fine on the Access objects.

And keep in mind that MDEs did not exist until Access 95 and were
not available in the UI until A97. Before that time, Jet user-level
security was the *only* option for securing your code.

Keep in mind also that MDEs have certain drawbacks (especially with
reports) that may make it impossible for a particular application to
be distributed as an MDE, so if you need to secure your design, then
only user-level security can do it in an MDB.

It's all part of the arsenal available to the developer for securing
the application, both the data and the program design.

I almost always distribute MDBs and don't apply any security at all,
and I don't have problems. But that's for single-client
applications. If I were distributing something more widely I'd
probably secure the design or deliver an MDE (I'm not sure which I'd
choose).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Albert D. Kallal]

>There are at least 4 or 5 companies

(foundations) that want to use my database program for their end-users
on private isolated PC's at home. There is not much I can do to make
them memeber and things like that. It will be to complicated to
distribute it this way.. But disabling the shift key and hiding the
Access toolbars is at least a good start.

if you need remote users over the internet...then read the following

http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html

And, if you are want a good article on how splitting works....

read this one

http://www.members.shaw.ca/AlbertKal...plit/index.htm
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[Albert D. Kallal]

>It's all part of the arsenal available to the developer for securing
the application, both the data and the program design.

Yes...you nailed it with the above!!!

ms-access is different!! You ask any developer of MOST platforms, and they
will not even consider using the database features to security design of
code and forms. If you asked a VB, or c++, vb.net, or just about ANY
platform developer, the idea of using database security DOES NOT apply to
that of application code and forms. The only real issue here is that
ms-access does include a database, and also includes workgroup security. So,
ms-access is able to cross borders here, but it is not the norm. How many
development tools include both workgroup security, and also a database?

My only real point here is that as a general rule in the software industry,
the workgroup security features of a database are not for that of a
developers needing to protect their appcation code and design. It just so
happens that ms-access *lets* you do this.

All too often, a user needs to hide the ms-access interface, and prevent
users from changing code or report designs. A mde with proper startup
options will hide all of ms-access, and the often suggested advice to use
security in this case is really bad advice.

I just want the readers to keep in mind that as a general intention here,
that security stuff is to restrict what parts of a application a user can
use...not prevent users from modifying the code, and programming design of
the application.

........ but you do correctly point out it is part of the arsenal of
ms-access......
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[David W. Fenton]

"Albert D. Kallal" <ka****@msn.com> wrote in
news:d15Nf.81287$B94.55846@pd7tw3no:

My only real point here is that as a general rule in the software
industry, the workgroup security features of a database are not
for that of a developers needing to protect their appcation code
and design.

My experience with VB apps that use a Jet back end is that they
never secure the data, either. I've many times poked around in the
Jet back ends of any number of non-Access applications and could
easily have corrupted the data or changed the design.

This is a matter of massive stupidity on the part of these
developers.

Thus, the practices of the industry in general do not, in my
opinion, have any bearing whatsoever on best practices in Access.
That nobody else secures code is not surprising when they don't even
bother to secure data.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Larry Linson]

"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:11*********************@v46g2000cwv.googlegro ups.com...

Really Funny!

No, not funny at all. They provided VB.NET and C# to work with Excel and
Word in the, then had to have _someplace_ to toss in the Access runtime
stuff, so there you are... the Access Developer Extensions, as they now call
them, which have not a thing in the world to do with Visual Studio, are in
the "Visual Studio Tools for Office 2003 System."

Larry Linson
Microsoft Access MVP

[Larry Linson]

"Oldie" <ke*@hiquad.demon.nl> wrote

Not really funny!

Gee, Oldie, I wish you could remember where that Access compiler was -- I've
wanted one as long as I could remember and would be willing to drop back a
few versions to be able to compile a standalone executable. But, I started
using Access within 60 days of its initial release, lead an Access user
group, was recognized with the MVP, and I never could find the compiler I
wanted.

Larry Linson
Microsoft Access MVP

[Oldie]

Pete Creswell wrote

There are a couple of ways:

1) In Tools|Startup you can specify a form tb opened when the app
starts.

2) You can create a macro named AutoExec and it will be executed when
the app starts.

I prefer #2 because it brings everything up to the surface where
somebody
can see it rather than burying the functionality in an option setting.

Thanks very much Peter, you have been very helpful. I think with your
solution and a block of the Shift key my application is as safe as I
want it to be.

I just need the developer now to distribute it!.

Thanks again

[Oldie]

Albert D. Kallal wrote:

if you need remote users over the internet...then read the following

http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html

And, if you are want a good article on how splitting works....

read this one

http://www.members.shaw.ca/AlbertKal...plit/index.htm
Of course my applcation is split right from the start in a data part
with just tables and their relations and the program part with the VBA
and macros.

The problem is that my users do not use the internet for this
application. Every user is a volunteer who is responsible to raise as
much money in his area for the foundation. So every user has his own
database data with around 1000 volunteers he has to trigger.

Thanks anyway for your support in trying to help me!