Access limitations regarding team development

I am looking for specific limitations in Access regarding team development of
databases (tables). If I understand correctly there can only be two designers
working on the database at any one time; one in the front-end and one in the
back-end. Are there other limitations to team development in Access?

If I understand correctly there can only be two designers working on the
database at any one time; one in the front-end and one in the back-end.

That is incorrect! Any number of designers can work on developing the tables
in the backend. Each designer can be working in a separate file creating his
set of tables. There needs to be a master backend file where when a designer
is completed with his part, his tables are imported into the master. When
all the designers are completed and all their tables are in the master, the
relationships can be created between all the tables in the backend.

Once the backend is completed, then any number of designers can work on the
frontend. Again there needs to be a master frontend where each designer's
work can be imported into when the the designer is complete with his part.

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications





"mar81018" wrote in message
...
I am looking for specific limitations in Access regarding team development
of
databases (tables). If I understand correctly there can only be two
designers
working on the database at any one time; one in the front-end and one in
the
back-end. Are there other limitations to team development in Access?

Are there other limitations to designing databases in Access?

"Steve" wrote:

If I understand correctly there can only be two designers working on the
database at any one time; one in the front-end and one in the back-end.

That is incorrect! Any number of designers can work on developing the tables
in the backend. Each designer can be working in a separate file creating his
set of tables. There needs to be a master backend file where when a designer
is completed with his part, his tables are imported into the master. When
all the designers are completed and all their tables are in the master, the
relationships can be created between all the tables in the backend.

Once the backend is completed, then any number of designers can work on the
frontend. Again there needs to be a master frontend where each designer's
work can be imported into when the the designer is complete with his part.

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications





"mar81018" wrote in message
...
I am looking for specific limitations in Access regarding team development
of
databases (tables). If I understand correctly there can only be two
designers
working on the database at any one time; one in the front-end and one in
the
back-end. Are there other limitations to team development in Access?

Take a look at Specifications in the Help file.

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications






"mar81018" wrote in message
...
Are there other limitations to designing databases in Access?

"Steve" wrote:

If I understand correctly there can only be two designers working on
the
database at any one time; one in the front-end and one in the back-end.


That is incorrect! Any number of designers can work on developing the
tables
in the backend. Each designer can be working in a separate file creating
his
set of tables. There needs to be a master backend file where when a
designer
is completed with his part, his tables are imported into the master. When
all the designers are completed and all their tables are in the master,
the
relationships can be created between all the tables in the backend.

Once the backend is completed, then any number of designers can work on
the
frontend. Again there needs to be a master frontend where each designer's
work can be imported into when the the designer is complete with his
part.

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications





"mar81018" wrote in message
...
I am looking for specific limitations in Access regarding team
development
of
databases (tables). If I understand correctly there can only be two
designers
working on the database at any one time; one in the front-end and one
in
the
back-end. Are there other limitations to team development in Access?

"Steve" wrote in message
nk.net...
If I understand correctly there can only be two designers working on the
database at any one time; one in the front-end and one in the back-end.

That is incorrect! Any number of designers can work on developing the
tables in the backend. Each designer can be working in a separate file
creating his set of tables. There needs to be a master backend file where
when a designer is completed with his part, his tables are imported into
the master. When all the designers are completed and all their tables are
in the master, the relationships can be created between all the tables in
the backend.

Once the backend is completed, then any number of designers can work on
the frontend. Again there needs to be a master frontend where each
designer's work can be imported into when the the designer is complete
with his part.

But really it takes about 3 minutes to input a table. The overall design is
what is important, and it makes no sense to have more than one person
independently designing the table structure. If a team _does_ design the
tables, it's more effective to have them all around a table discussing the
overall design and hashing out the best relational structure. After that,
implementing the design is a few hours' work for one person at most.

I do agree with Steve that you can have multiple files and import all the
components into one master file, but it seems to me to make more sense to do
that with the _frontend_, where having multiple people working on forms and
code makes more sense.

-Amy

it makes no sense to have more than one person independently designing
the table structure.

It makes perfect sense to have a team design the table structure in a large
multifaceted database. Each member of a team has his own functionality
expertise and is most familiar with the ins and outs of a segment of the
business. It's not effective at all to have a bunch of designers sit around
a table discussing the overall design and hashing out the best relational
structure. Numerous meetings occur and each meeting is low efficiency when
team members with little knowledge of the immediate subject being discussed
sit on their hands. What is effective is to have knowledgable people sit
around a table and develop a specification for the project and then to hand
the specification to a team of designers to create the table structure in a
modular approach. A good team leader (sometimes called a project manager)
can make this process highly efficient.

I have been there and done that on several projects for customers.

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications







"Amy Blankenship" wrote in message
...

"Steve" wrote in message
nk.net...
If I understand correctly there can only be two designers working on
the database at any one time; one in the front-end and one in the
back-end.

That is incorrect! Any number of designers can work on developing the
tables in the backend. Each designer can be working in a separate file
creating his set of tables. There needs to be a master backend file where
when a designer is completed with his part, his tables are imported into
the master. When all the designers are completed and all their tables are
in the master, the relationships can be created between all the tables in
the backend.

Once the backend is completed, then any number of designers can work on
the frontend. Again there needs to be a master frontend where each
designer's work can be imported into when the the designer is complete
with his part.

But really it takes about 3 minutes to input a table. The overall design
is what is important, and it makes no sense to have more than one person
independently designing the table structure. If a team _does_ design the
tables, it's more effective to have them all around a table discussing the
overall design and hashing out the best relational structure. After that,
implementing the design is a few hours' work for one person at most.

I do agree with Steve that you can have multiple files and import all the
components into one master file, but it seems to me to make more sense to
do that with the _frontend_, where having multiple people working on forms
and code makes more sense.

-Amy

On Jul 7, 3:58 pm, mar81018
wrote:
I am looking for specific limitations in Access regarding team development of
databases (tables).

In a team environment it's pretty much essential to have source
control and daily builds. I tried to implement Visual Source Safe
(used to ship with developer versions) in an Access team environment
but it was most unpopular so I never got to thinking about a build
process because everyone wanted to import objects 'by hand',
consequently the 'build' was forever breaking. I'd be interested to
hear about a team that successful builds from source control but the
vast majority of people around here (notably Access MVPs) seem to be
one man bands.

Jamie.

--

We dropped VSS integration because it was flaky.

We just use VSS to store our mdb's as binary
files. The only thing we miss is code differencing,
and even that didn't work properly in VSS.

We use a shell database, referencing separate
functional library databases, a shared report
database, and a common code library database.

We use a VB program to build, using the
undocumented make mde command.

(david)

Jamie Collins wrote:
On Jul 7, 3:58 pm, mar81018
wrote:
I am looking for specific limitations in Access regarding team development of
databases (tables).

In a team environment it's pretty much essential to have source
control and daily builds. I tried to implement Visual Source Safe
(used to ship with developer versions) in an Access team environment
but it was most unpopular so I never got to thinking about a build
process because everyone wanted to import objects 'by hand',
consequently the 'build' was forever breaking. I'd be interested to
hear about a team that successful builds from source control but the
vast majority of people around here (notably Access MVPs) seem to be
one man bands.

Jamie.

--

Hi David

"using the undocumented make mde command" - could you tell me more about
this command?
--
Regards
Chris


"DAVID" wrote:

We dropped VSS integration because it was flaky.

We just use VSS to store our mdb's as binary
files. The only thing we miss is code differencing,
and even that didn't work properly in VSS.

We use a shell database, referencing separate
functional library databases, a shared report
database, and a common code library database.

We use a VB program to build, using the
undocumented make mde command.

(david)

Jamie Collins wrote:
On Jul 7, 3:58 pm, mar81018
wrote:
I am looking for specific limitations in Access regarding team development of
databases (tables).

In a team environment it's pretty much essential to have source
control and daily builds. I tried to implement Visual Source Safe
(used to ship with developer versions) in an Access team environment
but it was most unpopular so I never got to thinking about a build
process because everyone wanted to import objects 'by hand',
consequently the 'build' was forever breaking. I'd be interested to
hear about a team that successful builds from source control but the
vast majority of people around here (notably Access MVPs) seem to be
one man bands.

Jamie.

--

Chris W wrote:
Hi David

"using the undocumented make mde command" - could you tell me more about
this command?

http://www.everythingaccess.com/tuto...sCmd-Functions


There is also a commercial product now that claims to do something
different:

http://www.eliansoft.com/amdec.html

Access uses standard VBA components, which use the standard MS compiler,
but there is no well-known way to automate compilation other than using
sendkeys or the undocumented syscmd.

(david)