Licencing of an Access Database - and other prerequisite's

[Gary]

Hi everyone,

I'm weighing up the pro's and con's of using a commercial contact
management system - like Act. or writing my own in access at the
moment.

I have used Act for the past couple of weeks to trial it and i really
don't think it's anything exceptional. It has crashed a couple of times
as well!

If i go down the access route, I will need to make the database fully
networkable. There are about 12 users that will need access to the
database in my office. As well as the network access, I am also not
sure how I stand with licencing? If i write this database does every
user have to have a licence for access on their machine to use it? that
brings me on to my third point, should i make the database 'stand
alone' - is this hard to do?
So my questions are: -

q1.
what considerations will i need, in light of the fact that i want a
networked database. with the data residing on the fileserver. should i
create the front-end's on the users machines and just have the data on
the server - or should I put the whole database on the server?

q2.
how do i stand with writing a database for 12+ users, from a licencing
perspective?

q3.
should i make the database standalone?

Thank you all in advance,
Gary.

 

[Douglas J Steele]

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)

q1.
what considerations will i need, in light of the fact that i want a
networked database. with the data residing on the fileserver. should i
create the front-end's on the users machines and just have the data on
the server - or should I put the whole database on the server?

The application should definitely be split into a front-end (containing the
queries, forms, reports, macros and modules), linked to a back-end
(containing the tables). The back-end should be on the server: each user
should have his/her own copy of the front-end, ideally on their hard drive.

q2.
how do i stand with writing a database for 12+ users, from a licencing
perspective?

Each user requires a copy of Access installed on his/her workstation. Note
that it is possible to purchase a Developer edition of Access that includes
a royalty-free run-time version of Access. You need to purchase the
following in order to create an Access 2003 runtime application:

- Microsoft Access 2003
- Visual Studio Tools for Office 2003 (which includes the Access 2003
Developer Extensions)

The ADE is the product that gives you the license to deploy the 2003 runtime
components and you have to have Access 2003 installed in order to install
the ADE.

If you're using MSDN, note that while VSTO is available in all subscription
levels of MSDN, the Access Developer Extensions are not included with all
versions. ADE is only available at Universal level.

The stand-alone VSTO box includes both VSTO and the ADE.

See http://msdn.microsoft.com/vstudio/office/officetools.aspx for more
details

While VSTO isn't that cheap, it should be cheaper than 12 copies of Access.

q3.
should i make the database standalone?

If by "standalone", you mean create it so that Access isn't required, that
isn't possible. You'd have to write the application in some other product
(like VB, VC++, VB.Net, C#.Net, Delphi, etc.). You could still store the
data in a Jet database (MDB file)

 

[Albert D.Kallal]

If i write this database does every
user have to have a licence for access on their machine to use it?

As mentioned in the other post, you can create a runtime version.

that
brings me on to my third point, should i make the database 'stand
alone' - is this hard to do?

The deveoeprs edtion esstenclity allows you to do the above.

So my questions are: -

q1.
what considerations will i need, in light of the fact that i want a
networked database. with the data residing on the fileserver. should i
create the front-end's on the users machines and just have the data on
the server - or should I put the whole database on the server?

The fact that you are asking this qeustion menas that you got a good deal of
things to learn.
While that ACT might not seem like a big deal, consider they likey had 5
developers working on the product for 5 years. Rigth away, you got 25 man
eyars of work. This is simular to you building a house. I think most of us
could scan the inetent, and learn how to build a house. The problem is that
it would take me likey 15 years to build that house.

So, if you done any amount serous develpument in sma-ccess, it would be
crtyasl clear that you MUST split the database for JUST reasons of
develpuemt.

Anway, to get you up to speed as to why you split, you can read the
follwing:

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

So, if you willing to put in the time to learn ms-access, then this is
certaly doable. However, a licens of ACT costs less then 1 week of work, and
you have to decide the tradoff in time/resouces here.

q2.
how do i stand with writing a database for 12+ users, from a licencing
perspective?

q3.
should i make the database standalone?

I note 100% sure what you mean by stand-alone. As mentioned, you can do this
with a runtime version of ms-access. This assume however that you are
experienced developer with ms-access. For example, do you now as a mater of
the development process hide all of the ms-access interface? Do you provide
custom menus now?

For example, you can read the following as to why menus are a good idea.The
screen shots happen to be from ms-access, but they could have been from any
platform...

http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFriendly.htm

 

[dbahooker]

gary

don't use a MDB for this; use MSDE or SQL Server with Access Data
Projects.

I do reccomed the access runtime more often than other developers.
It's a free way to give people that dont have access the ability to use
access apps. I just like how it is so secure-- it doesn't give end
users any ability to tramp through your app.

I dont know the licensing specifics with the Access Runtime. I think
that the ART exe is included on the Office 2003 professional disc.

-Aaron