Access message "cannot define field more than once"

[Bbrown]

When creating table, got error 3191. All my field names were different. Why
error?

 

[Jeff Boyce]

"creating field" ... how?

What happens if you change the fieldname for which this happens to something
arbitrary?

Have you saved a copy of your database and run Compact & Repair?

More info, please


Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Bbrown]

There are field names which are similar, i.e. Mechanical Final, Mechanical
Rough. Does it have something to do with the first few characters being the
same?

 

[Jeff Boyce]

No, it shouldn't ... but thanks for providing an example!

If your proposed fieldnames are [Mechanical Final], [Mechanical Rough],
there is a very good chance that your table is not a well-normalized
relational structure, but rather, is a ... spreadsheet! Embedding data
('rough', 'final', ...) in field names is not a good database design
approach.

If you'll provide a bit more specific information about the data you want to
store and your proposed structure, folks here may be able to offer you
alternate approaches that help you make better use of Access'
relationally-oriented features/functions.

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Bbrown]

I'm trying to set up a data base which tracks calls for building inspections.
I want to have a table which has a drop down listing all the possible
inspections that can be called in. Then I will have a "call center" which
will take the caller's information and the operator chooses which inspection
is being requested. It is a finite list which has probably 30 possibilities.
When you do a mechanical inspection, it can be a "rough" or "final". And,
when doing plumbing, the inspection could be a "plumbing rough", "plumbing
underground", "plumbing final", and so on... So, for each phase of a
building, there could be several types of mechcanical, plumbing, electrical,
etc.

Too much, or too little info?

No, it shouldn't ... but thanks for providing an example!

If your proposed fieldnames are [Mechanical Final], [Mechanical Rough],
there is a very good chance that your table is not a well-normalized
relational structure, but rather, is a ... spreadsheet! Embedding data
('rough', 'final', ...) in field names is not a good database design
approach.

If you'll provide a bit more specific information about the data you want to
store and your proposed structure, folks here may be able to offer you
alternate approaches that help you make better use of Access'
relationally-oriented features/functions.

Regards

Jeff Boyce
Microsoft Office/Access MVP

There are field names which are similar, i.e. Mechanical Final, Mechanical
Rough. Does it have something to do with the first few characters being
the
same?

 

[Jeff Boyce]

It sounds like your situation can have one of several "topics" (e.g.,
mechanical, plumbing, electrical, ...), and for each of those, one of
several "types" (e.g., rough, underground, final, ...).

If that's an accurate paraphrasing, then you probably want to use TWO
drop-down (combobox) lists in your form (by the way, in your FORM, not in
your table. You don't want users to be working directly in the tables.)
The first combobox lets the call center staff pick the topic, the second
lets them narrow it down.

Does that fit with your situation?

Regards

Jeff Boyce
Microsoft Office/Access MVP

I'm trying to set up a data base which tracks calls for building
inspections.
I want to have a table which has a drop down listing all the possible
inspections that can be called in. Then I will have a "call center" which
will take the caller's information and the operator chooses which
inspection
is being requested. It is a finite list which has probably 30
possibilities.
When you do a mechanical inspection, it can be a "rough" or "final". And,
when doing plumbing, the inspection could be a "plumbing rough", "plumbing
underground", "plumbing final", and so on... So, for each phase of a
building, there could be several types of mechcanical, plumbing,
electrical,
etc.

Too much, or too little info?

No, it shouldn't ... but thanks for providing an example!

If your proposed fieldnames are [Mechanical Final], [Mechanical Rough],
there is a very good chance that your table is not a well-normalized
relational structure, but rather, is a ... spreadsheet! Embedding data
('rough', 'final', ...) in field names is not a good database design
approach.

If you'll provide a bit more specific information about the data you want
to
store and your proposed structure, folks here may be able to offer you
alternate approaches that help you make better use of Access'
relationally-oriented features/functions.

Regards

Jeff Boyce
Microsoft Office/Access MVP

There are field names which are similar, i.e. Mechanical Final,
Mechanical
Rough. Does it have something to do with the first few characters
being
the
same?

:

"creating field" ... how?

What happens if you change the fieldname for which this happens to
something
arbitrary?

Have you saved a copy of your database and run Compact & Repair?

More info, please


Regards

Jeff Boyce
Microsoft Office/Access MVP

When creating table, got error 3191. All my field names were
different.
Why
error?

 

[Bbrown]

OK, looks like I'm going down the wrong path. Unfortunately, I don't have a
user guide, as I bought an unboxed Access 2007... I was building the

So, I think I need to step back. I want to:

1) List and track status of permits and their inspections, including dates
inspections performed and inspector name.
2) Take and track calls from individuals who need to have building code
inspections performed
3) Close out permits when they are completed.

To get started, do I need to design a switchboard with choices of actions
and then forms to fulfill those actions? Or start with the forms and combine
them into a switchboard?

I had a beginner Access class long ago and then worked with a completed
Access database application, so I know what it can do, just not how to do it.
I need a "dummies" book!

I'm trying to set up a data base which tracks calls for building inspections.
I want to have a table which has a drop down listing all the possible
inspections that can be called in. Then I will have a "call center" which
will take the caller's information and the operator chooses which inspection
is being requested. It is a finite list which has probably 30 possibilities.
When you do a mechanical inspection, it can be a "rough" or "final". And,
when doing plumbing, the inspection could be a "plumbing rough", "plumbing
underground", "plumbing final", and so on... So, for each phase of a
building, there could be several types of mechcanical, plumbing, electrical,
etc.

Too much, or too little info?

No, it shouldn't ... but thanks for providing an example!

If your proposed fieldnames are [Mechanical Final], [Mechanical Rough],
there is a very good chance that your table is not a well-normalized
relational structure, but rather, is a ... spreadsheet! Embedding data
('rough', 'final', ...) in field names is not a good database design
approach.

If you'll provide a bit more specific information about the data you want to
store and your proposed structure, folks here may be able to offer you
alternate approaches that help you make better use of Access'
relationally-oriented features/functions.

Regards

Jeff Boyce
Microsoft Office/Access MVP

There are field names which are similar, i.e. Mechanical Final, Mechanical
Rough. Does it have something to do with the first few characters being
the
same?

:

"creating field" ... how?

What happens if you change the fieldname for which this happens to
something
arbitrary?

Have you saved a copy of your database and run Compact & Repair?

More info, please


Regards

Jeff Boyce
Microsoft Office/Access MVP

When creating table, got error 3191. All my field names were
different.
Why
error?

 

[Jeff Boyce]

You may want to step back even further!

I generally suggest to folks who are trying to build an MS Access
application for the first time that there are three learning curves they'll
need to fight their way up:

1. relational database design and normalization (the TABLES come first, not
the forms)
2. Access tricks and tips (how does Access do stuff)
3. user(-friendly) graphical interface design (how to make it pretty and
usable is LAST)

Oh yes, one more thing ... if you've not developed an application before,
that's another learning curve!

If you won't be given the time and resources you need to get past these
three curves, or if the project is due NOW, you may want to start looking
for someone who has already surmouted those curves...

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

OK, looks like I'm going down the wrong path. Unfortunately, I don't have
a
user guide, as I bought an unboxed Access 2007... I was building the

So, I think I need to step back. I want to:

1) List and track status of permits and their inspections, including
dates
inspections performed and inspector name.
2) Take and track calls from individuals who need to have building code
inspections performed
3) Close out permits when they are completed.

To get started, do I need to design a switchboard with choices of actions
and then forms to fulfill those actions? Or start with the forms and
combine
them into a switchboard?

I had a beginner Access class long ago and then worked with a completed
Access database application, so I know what it can do, just not how to do
it.
I need a "dummies" book!

I'm trying to set up a data base which tracks calls for building
inspections.
I want to have a table which has a drop down listing all the possible
inspections that can be called in. Then I will have a "call center"
which
will take the caller's information and the operator chooses which
inspection
is being requested. It is a finite list which has probably 30
possibilities.
When you do a mechanical inspection, it can be a "rough" or "final".
And,
when doing plumbing, the inspection could be a "plumbing rough",
"plumbing
underground", "plumbing final", and so on... So, for each phase of a
building, there could be several types of mechcanical, plumbing,
electrical,
etc.

Too much, or too little info?

No, it shouldn't ... but thanks for providing an example!

If your proposed fieldnames are [Mechanical Final], [Mechanical Rough],
there is a very good chance that your table is not a well-normalized
relational structure, but rather, is a ... spreadsheet! Embedding data
('rough', 'final', ...) in field names is not a good database design
approach.

If you'll provide a bit more specific information about the data you
want to
store and your proposed structure, folks here may be able to offer you
alternate approaches that help you make better use of Access'
relationally-oriented features/functions.

Regards

Jeff Boyce
Microsoft Office/Access MVP


There are field names which are similar, i.e. Mechanical Final,
Mechanical
Rough. Does it have something to do with the first few characters
being
the
same?

:

"creating field" ... how?

What happens if you change the fieldname for which this happens to
something
arbitrary?

Have you saved a copy of your database and run Compact & Repair?

More info, please


Regards

Jeff Boyce
Microsoft Office/Access MVP

When creating table, got error 3191. All my field names were
different.
Why
error?

 

[Bbrown]

Thanks, Jeff. I have designed a couple of simple databases, mainly address
tracking.

I'm going to muddle through this for a while. I love a challenge. I think
I'll take advantage of some of the templates and try to revise them. I've
already made a contractor's listing and a form to input new ones. Then I'll
tackle the permit table and inspection table and see how I can relate them to
one another.

You may want to step back even further!

I generally suggest to folks who are trying to build an MS Access
application for the first time that there are three learning curves they'll
need to fight their way up:

1. relational database design and normalization (the TABLES come first, not
the forms)
2. Access tricks and tips (how does Access do stuff)
3. user(-friendly) graphical interface design (how to make it pretty and
usable is LAST)

Oh yes, one more thing ... if you've not developed an application before,
that's another learning curve!

If you won't be given the time and resources you need to get past these
three curves, or if the project is due NOW, you may want to start looking
for someone who has already surmouted those curves...

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

OK, looks like I'm going down the wrong path. Unfortunately, I don't have
a
user guide, as I bought an unboxed Access 2007... I was building the

So, I think I need to step back. I want to:

1) List and track status of permits and their inspections, including
dates
inspections performed and inspector name.
2) Take and track calls from individuals who need to have building code
inspections performed
3) Close out permits when they are completed.

To get started, do I need to design a switchboard with choices of actions
and then forms to fulfill those actions? Or start with the forms and
combine
them into a switchboard?

I had a beginner Access class long ago and then worked with a completed
Access database application, so I know what it can do, just not how to do
it.
I need a "dummies" book!

I'm trying to set up a data base which tracks calls for building
inspections.
I want to have a table which has a drop down listing all the possible
inspections that can be called in. Then I will have a "call center"
which
will take the caller's information and the operator chooses which
inspection
is being requested. It is a finite list which has probably 30
possibilities.
When you do a mechanical inspection, it can be a "rough" or "final".
And,
when doing plumbing, the inspection could be a "plumbing rough",
"plumbing
underground", "plumbing final", and so on... So, for each phase of a
building, there could be several types of mechcanical, plumbing,
electrical,
etc.

Too much, or too little info?

:

No, it shouldn't ... but thanks for providing an example!

If your proposed fieldnames are [Mechanical Final], [Mechanical Rough],
there is a very good chance that your table is not a well-normalized
relational structure, but rather, is a ... spreadsheet! Embedding data
('rough', 'final', ...) in field names is not a good database design
approach.

If you'll provide a bit more specific information about the data you
want to
store and your proposed structure, folks here may be able to offer you
alternate approaches that help you make better use of Access'
relationally-oriented features/functions.

Regards

Jeff Boyce
Microsoft Office/Access MVP


There are field names which are similar, i.e. Mechanical Final,
Mechanical
Rough. Does it have something to do with the first few characters
being
the
same?

:

"creating field" ... how?

What happens if you change the fieldname for which this happens to
something
arbitrary?

Have you saved a copy of your database and run Compact & Repair?

More info, please


Regards

Jeff Boyce
Microsoft Office/Access MVP

When creating table, got error 3191. All my field names were
different.
Why
error?

 

[Jeff Boyce]

Keep posting your questions ... other folks can benefit from learning the
solutions.

Good luck on your project!

Regards

Jeff Boyce
Microsoft Office/Access MVP

Thanks, Jeff. I have designed a couple of simple databases, mainly
address
tracking.

I'm going to muddle through this for a while. I love a challenge. I think
I'll take advantage of some of the templates and try to revise them. I've
already made a contractor's listing and a form to input new ones. Then
I'll
tackle the permit table and inspection table and see how I can relate them
to
one another.

You may want to step back even further!

I generally suggest to folks who are trying to build an MS Access
application for the first time that there are three learning curves
they'll
need to fight their way up:

1. relational database design and normalization (the TABLES come first,
not
the forms)
2. Access tricks and tips (how does Access do stuff)
3. user(-friendly) graphical interface design (how to make it pretty and
usable is LAST)

Oh yes, one more thing ... if you've not developed an application before,
that's another learning curve!

If you won't be given the time and resources you need to get past these
three curves, or if the project is due NOW, you may want to start looking
for someone who has already surmouted those curves...

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

OK, looks like I'm going down the wrong path. Unfortunately, I don't
have
a
user guide, as I bought an unboxed Access 2007... I was building the

So, I think I need to step back. I want to:

1) List and track status of permits and their inspections, including
dates
inspections performed and inspector name.
2) Take and track calls from individuals who need to have building
code
inspections performed
3) Close out permits when they are completed.

To get started, do I need to design a switchboard with choices of
actions
and then forms to fulfill those actions? Or start with the forms and
combine
them into a switchboard?

I had a beginner Access class long ago and then worked with a completed
Access database application, so I know what it can do, just not how to
do
it.
I need a "dummies" book!

:

I'm trying to set up a data base which tracks calls for building
inspections.
I want to have a table which has a drop down listing all the possible
inspections that can be called in. Then I will have a "call center"
which
will take the caller's information and the operator chooses which
inspection
is being requested. It is a finite list which has probably 30
possibilities.
When you do a mechanical inspection, it can be a "rough" or "final".
And,
when doing plumbing, the inspection could be a "plumbing rough",
"plumbing
underground", "plumbing final", and so on... So, for each phase of a
building, there could be several types of mechcanical, plumbing,
electrical,
etc.

Too much, or too little info?

:

No, it shouldn't ... but thanks for providing an example!

If your proposed fieldnames are [Mechanical Final], [Mechanical
Rough],
there is a very good chance that your table is not a well-normalized
relational structure, but rather, is a ... spreadsheet! Embedding
data
('rough', 'final', ...) in field names is not a good database design
approach.

If you'll provide a bit more specific information about the data you
want to
store and your proposed structure, folks here may be able to offer
you
alternate approaches that help you make better use of Access'
relationally-oriented features/functions.

Regards

Jeff Boyce
Microsoft Office/Access MVP


There are field names which are similar, i.e. Mechanical Final,
Mechanical
Rough. Does it have something to do with the first few characters
being
the
same?

:

"creating field" ... how?

What happens if you change the fieldname for which this happens
to
something
arbitrary?

Have you saved a copy of your database and run Compact & Repair?

More info, please


Regards

Jeff Boyce
Microsoft Office/Access MVP

When creating table, got error 3191. All my field names were
different.
Why
error?