Whut I dew?

[davegb]

I changed the name of an existing table, and a bunch of new tables
appeared in the list, all with black arrows to their left, pointing to
the right. When I click on any of them, a message box appears, "Could
not find the file C:\.......\Temp\wiz1F.tmp". What did I do? Should I
be comtemplating seppuku (self-disembowlment with my samurai sword) or
just jump a tramp steamer to the South Pacific?
Help! And thanks.

[Steve]

Tables listed with black arrows next to their names are linked tables.
Try relinking your tables (right click in database window and choose
'Link Tables').

[davegb]

Steve wrote:

Tables listed with black arrows next to their names are linked tables.
Try relinking your tables (right click in database window and choose
'Link Tables').

Thanks for your reply. I wouldn't know what to link them to, so I
deleted them.

[Jeff]

Not a good practice to delete something if you are not sure what it is.

Did you create this database?

It is pretty hard to link a stack of tables accidentally? At least, as far
as I know.

Does anything still work?

Jeff

"davegb" <da****@safebrowse.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Steve wrote:

Tables listed with black arrows next to their names are linked tables.
Try relinking your tables (right click in database window and choose
'Link Tables').

Thanks for your reply. I wouldn't know what to link them to, so I
deleted them.

[Tom van Stiphout]

On 9 Jan 2006 12:58:15 -0800, "davegb" <da****@safebrowse.com> wrote:

Why not restore a backup from before the mishap?
-Tom.

I changed the name of an existing table, and a bunch of new tables
appeared in the list, all with black arrows to their left, pointing to
the right. When I click on any of them, a message box appears, "Could
not find the file C:\.......\Temp\wiz1F.tmp". What did I do? Should I
be comtemplating seppuku (self-disembowlment with my samurai sword) or
just jump a tramp steamer to the South Pacific?
Help! And thanks.

[davegb]

Tom van Stiphout wrote:

On 9 Jan 2006 12:58:15 -0800, "davegb" <da****@safebrowse.com> wrote:

Why not restore a backup from before the mishap?
-Tom.

I changed the name of an existing table, and a bunch of new tables
appeared in the list, all with black arrows to their left, pointing to
the right. When I click on any of them, a message box appears, "Could
not find the file C:\.......\Temp\wiz1F.tmp". What did I do? Should I
be comtemplating seppuku (self-disembowlment with my samurai sword) or
just jump a tramp steamer to the South Pacific?
Help! And thanks.

Thanks for both of your replies.
I talked with one of our Access experts here, and he was dumbfounded.
Never saw anything like it before. Everything worked, so I went ahead
and deleted them. It seems to be ok. I have a weird error message about
an apparently unrelated field that keeps telling me I have the wrong
data type in the field, which I don't. It's a numeric field with a
number in it. But I don't see any connection between that and the
mysterious tables Access created and I deleted. I knew I was taking a
risk deleting the tables, but didn't know what else to do. Will have to
see if it works out.

[davegb]

davegb wrote:

Tom van Stiphout wrote:

On 9 Jan 2006 12:58:15 -0800, "davegb" <da****@safebrowse.com> wrote:

Why not restore a backup from before the mishap?
-Tom.

I changed the name of an existing table, and a bunch of new tables
appeared in the list, all with black arrows to their left, pointing to
the right. When I click on any of them, a message box appears, "Could
not find the file C:\.......\Temp\wiz1F.tmp". What did I do? Should I
be comtemplating seppuku (self-disembowlment with my samurai sword) or
just jump a tramp steamer to the South Pacific?
Help! And thanks.

Thanks for both of your replies.
I talked with one of our Access experts here, and he was dumbfounded.
Never saw anything like it before. Everything worked, so I went ahead
and deleted them. It seems to be ok. I have a weird error message about
an apparently unrelated field that keeps telling me I have the wrong
data type in the field, which I don't. It's a numeric field with a
number in it. But I don't see any connection between that and the
mysterious tables Access created and I deleted. I knew I was taking a
risk deleting the tables, but didn't know what else to do. Will have to
see if it works out.

I'm now wondering if the two problems aren't related. Ever since I
deleted the mysterious tables, whenever I create a combo box which
accesses the main table, when I switch to the Form view and tab from
field to field, when I tab out of any of the combo boxes, I get the
same message. "The value you entered isn't valid for this field. For
example, you may have entered text in a numeric field or a number that
is larger than the field size setting permits." This is incorrect, the
field sizes and types match in every case.
Any ideas? TIA

[David W. Fenton]

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:

I'm now wondering if the two problems aren't related. Ever since I
deleted the mysterious tables, whenever I create a combo box which
accesses the main table, when I switch to the Form view and tab
from field to field, when I tab out of any of the combo boxes, I
get the same message. "The value you entered isn't valid for this
field. For example, you may have entered text in a numeric field
or a number that is larger than the field size setting permits."
This is incorrect, the field sizes and types match in every case.
Any ideas?

Do you perhaps have lookups defined in any of your tables? If one of
them is based on a linked table, and you deleted the link, it could
perhaps cause problems like what you've described.

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

[davegb]

David W. Fenton wrote:

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:

I'm now wondering if the two problems aren't related. Ever since I
deleted the mysterious tables, whenever I create a combo box which
accesses the main table, when I switch to the Form view and tab
from field to field, when I tab out of any of the combo boxes, I
get the same message. "The value you entered isn't valid for this
field. For example, you may have entered text in a numeric field
or a number that is larger than the field size setting permits."
This is incorrect, the field sizes and types match in every case.
Any ideas?
Do you perhaps have lookups defined in any of your tables? If one of
them is based on a linked table, and you deleted the link, it could
perhaps cause problems like what you've described.

Thanks for your reply. I was taught to never do lookups (10
Commandments), so no, there aren't any in the database.

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

[Mal Reeve]

A WILD GUESS.....and I have no idea HOW it would happen..,.
but form the title you describe..."file C:\.......\Temp\wiz1F.tmp"
emphasis on the WIZ
and the behaviour you describe with comboboxes...
I would guess that you have somehow Viewed...and then deleted the inbuild
wizards for combobox creation, etc.

I would probably create a new database (Blank)...then import all your
tables, queries etc. etc. into that new one....and see if that helps.

HTH
Mal.

"davegb" <da****@safebrowse.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

I changed the name of an existing table, and a bunch of new tables
appeared in the list, all with black arrows to their left, pointing to
the right. When I click on any of them, a message box appears, "Could
not find the file C:\.......\Temp\wiz1F.tmp". What did I do? Should I
be comtemplating seppuku (self-disembowlment with my samurai sword) or
just jump a tramp steamer to the South Pacific?
Help! And thanks.

[Trevor Best]

Jeff wrote:

Not a good practice to delete something if you are not sure what it is.

In the case of a linked table that's broken, no better or worse than
leaving it there, the code (if any) that access's it won't work either
way. Unless of course this is a shared database on a network drive and
the files do exist on somebody else's c: drive.

[Jeff]

I was talking generally. It seems to me that deleting anything is a bit
dangerous when you are not sure what it is, why it is there etc.

Jeff

"Trevor Best" <go**********@besty.org.uk> wrote in message
news:43*********************@news.zen.co.uk...

Jeff wrote:

Not a good practice to delete something if you are not sure what it is.

In the case of a linked table that's broken, no better or worse than
leaving it there, the code (if any) that access's it won't work either
way. Unless of course this is a shared database on a network drive and the
files do exist on somebody else's c: drive.

[Steve]

I agree with Jeff. Before I make a big change to something I don't
fully understand, I back up my database. Then if my change breaks the
system, I can just start over with the backup.

[davegb]

Steve wrote:

I agree with Jeff. Before I make a big change to something I don't
fully understand, I back up my database. Then if my change breaks the
system, I can just start over with the backup.

Which is something I'm in the habit of doing in other software. Just
not used to having to exit the program and save a dup by copying the
original insteat of doing a "Save as", like in every other Windoze
software I've ever used. Of course, my impulsive nature doesn't help
much!
Thanks for the replies!

[davegb]

Mal Reeve wrote:

A WILD GUESS.....and I have no idea HOW it would happen..,.
but form the title you describe..."file C:\.......\Temp\wiz1F.tmp"
emphasis on the WIZ
and the behaviour you describe with comboboxes...
I would guess that you have somehow Viewed...and then deleted the inbuild
wizards for combobox creation, etc.

I would probably create a new database (Blank)...then import all your
tables, queries etc. etc. into that new one....and see if that helps.
Thanks for the reply. I was afraid someone was going to suggest that.
But I think that's probably the solution. Thank heaven it's not a large
database.

HTH
Mal.

"davegb" <da****@safebrowse.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

I changed the name of an existing table, and a bunch of new tables
appeared in the list, all with black arrows to their left, pointing to
the right. When I click on any of them, a message box appears, "Could
not find the file C:\.......\Temp\wiz1F.tmp". What did I do? Should I
be comtemplating seppuku (self-disembowlment with my samurai sword) or
just jump a tramp steamer to the South Pacific?
Help! And thanks.

[davegb]

Mal Reeve wrote:

A WILD GUESS.....and I have no idea HOW it would happen..,.
but form the title you describe..."file C:\.......\Temp\wiz1F.tmp"
emphasis on the WIZ
and the behaviour you describe with comboboxes...
I would guess that you have somehow Viewed...and then deleted the inbuild
wizards for combobox creation, etc.

I would probably create a new database (Blank)...then import all your
tables, queries etc. etc. into that new one....and see if that helps.
Thanks for the reply. I was afraid someone was going to suggest that.
But I think that's probably the solution. Thank heaven it's not a large

database.
I'm obviously new to Access and database work in general. I've worked
with quirky software before, many times. Is it just from a beginner's
POV, or is Access considered quirky by experts?
Sure seems strange to me that by renaming a table, the software could
automatically create a bunch of tables with weird names, no explanation
whatever, that when deleted, corrupt the database!

HTH
Mal.

"davegb" <da****@safebrowse.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

I changed the name of an existing table, and a bunch of new tables
appeared in the list, all with black arrows to their left, pointing to
the right. When I click on any of them, a message box appears, "Could
not find the file C:\.......\Temp\wiz1F.tmp". What did I do? Should I
be comtemplating seppuku (self-disembowlment with my samurai sword) or
just jump a tramp steamer to the South Pacific?
Help! And thanks.

[Arno R]

"davegb" <da****@safebrowse.com> schreef in bericht news:11**********************@g49g2000cwa.googlegr oups.com...

Mal Reeve wrote:

A WILD GUESS.....and I have no idea HOW it would happen..,.
but form the title you describe..."file C:\.......\Temp\wiz1F.tmp"
emphasis on the WIZ
and the behaviour you describe with comboboxes...
I would guess that you have somehow Viewed...and then deleted the inbuild
wizards for combobox creation, etc.

I would probably create a new database (Blank)...then import all your
tables, queries etc. etc. into that new one....and see if that helps.

Thanks for the reply. I was afraid someone was going to suggest that.
But I think that's probably the solution. Thank heaven it's not a large
database.

Since you can import in *one step*, size doesn't matter very much.
It is simple:
File-Get external data. Just click on 'select all' on the various tabs.
Don't forget to import your relations, toolbars and such (hit options).

Arno R

[davegb]

Arno R wrote:

"davegb" <da****@safebrowse.com> schreef in bericht news:11**********************@g49g2000cwa.googlegr oups.com...

Mal Reeve wrote:

A WILD GUESS.....and I have no idea HOW it would happen..,.
but form the title you describe..."file C:\.......\Temp\wiz1F.tmp"
emphasis on the WIZ
and the behaviour you describe with comboboxes...
I would guess that you have somehow Viewed...and then deleted the inbuild
wizards for combobox creation, etc.

I would probably create a new database (Blank)...then import all your
tables, queries etc. etc. into that new one....and see if that helps.

Thanks for the reply. I was afraid someone was going to suggest that.
But I think that's probably the solution. Thank heaven it's not a large
database.

Since you can import in *one step*, size doesn't matter very much.
It is simple:
File-Get external data. Just click on 'select all' on the various tabs.
Don't forget to import your relations, toolbars and such (hit options).

Arno R

Thanks for your reply, Arno. It saved me some time. I copied in
everything the first time, but the problem with the one form was still
there. So I brought it all in again, but this time skipped the
offending form. Everything seems good to go, so far.

[David W. Fenton]

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@g43g2000cwa.googlegr oups.com:

is Access considered quirky by experts?
Nope.
Sure seems strange to me that by renaming a table, the software
could automatically create a bunch of tables with weird names, no
explanation whatever, that when deleted, corrupt the database!

Do you have Name AutoCorrect turned on?

If so, TURN IT OFF. It's one of those typical Microsoft features
that sounds great on paper, but actually leads to numerous serious
problems if you actually try to use it.

I've *never* used it, and have not had any problems.

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

[davegb]

David W. Fenton wrote:

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@g43g2000cwa.googlegr oups.com:

is Access considered quirky by experts?

Nope.

Sure seems strange to me that by renaming a table, the software
could automatically create a bunch of tables with weird names, no
explanation whatever, that when deleted, corrupt the database!

Do you have Name AutoCorrect turned on?

If so, TURN IT OFF. It's one of those typical Microsoft features
that sounds great on paper, but actually leads to numerous serious
problems if you actually try to use it.

I've *never* used it, and have not had any problems.

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

Thanks for the reply. To your knowledge is "Name AutoCorrect"
specifically responsible for this problem, of is this a generic
comment? Just curious.

[David W. Fenton]

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@z14g2000cwz.googlegr oups.com:

David W. Fenton wrote:

Do you have Name AutoCorrect turned on?

If so, TURN IT OFF. It's one of those typical Microsoft features
that sounds great on paper, but actually leads to numerous
serious problems if you actually try to use it.

I've *never* used it, and have not had any problems.

Thanks for the reply. To your knowledge is "Name AutoCorrect"
specifically responsible for this problem, of is this a generic
comment? Just curious.

I have no specific information. It seems like it could be vaguely
related, given that Name AutoCorrect has to keep its own data
structures somewhere in the background. The fact that things
appeared that were previously invisible suggests to me a slight
possibility that something broke in Name AutoCorrect and you started
seeing things that were supposed to be hidden.

But, no, I have no specific evidence that this is the case.

You should still turn it off, though.

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

[Steve]

Allen Browne (http://www.allenbrowne.com) has an entire page dedicated
to the problems that Name AutoCorrect causes. You may want to take a
look at that list for future reference.

[davegb]

Steve wrote:

Allen Browne (http://www.allenbrowne.com) has an entire page dedicated
to the problems that Name AutoCorrect causes. You may want to take a
look at that list for future reference.

Thanks to both Steve and David. Being the sceptic that I am, I had to
do some online research before I was willing to turn off this feature
entirely. I'm taking your advice and turning this feature off.
It's interesting to me how many parallels there are between Access,
which I'm just learning, and MS Project, in which I'm an expert. There
are a zillion hidden "rules" to properly using the software which make
for a steep learning curve. There's underlying theory you have to
understand to make it "go". And there are things MS calls "features"
which experienced users call "glitches". I'm feeling the frustration I
see in so many of my Project students. I'm told empathy builds
character...

[David W. Fenton]

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:

There's underlying theory you have to
understand to make it "go".
It's a database application. Thus, knowing theory of database design
is going to help a lot.

FWIW, most of the Access sample databases are very poorly designed,
schema-wise.
. . . And there are things MS calls "features"
which experienced users call "glitches".

Most of the those in Access are things that were implemented with
the best of intentions to make something easier for novices.
Unfortunately, these features were not designed very well, and most
of them are better turned off for anyone who wants to progress
beyond the most elementary stage.

Access is not a program like Word. It's a development platform with
a database engine. That makes it at least an order of magnitude more
complicated than the vast majority of applications that most people
are accustomed to dealing with. This often makes users of simpler
applications think that Access is badly designed, since it's som
complex, but it is as complex as it needs to be for what it is
designed to do, but most people don't have the right expectations,
since most of the apps they've used are of a completely different
type (document-based apps, like Word or Excel).

Every other program that is trying to accomplish the same thing has
copied a great deal from Access, and has exactly the same levels of
complexity as Access. The only one that might be easier in this
regard is FileMaker Pro, but it also lacks the same depth of
complexity in the programming language, as well as lacking the
enormous interoperability that comes from Access having COM built
into it.

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

[Terry Kreft]

I still think the people who were involved in implementing AutoCorrect in a
database application should be hit soundly with a large bat until they get
the concept of boilerplate.
--

Terry Kreft
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:
<SNIP>

. . . And there are things MS calls "features"
which experienced users call "glitches".

Most of the those in Access are things that were implemented with
the best of intentions to make something easier for novices.

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

[teddysnips]

davegb wrote:

David W. Fenton wrote:

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:

I'm now wondering if the two problems aren't related. Ever since I
deleted the mysterious tables, whenever I create a combo box which
accesses the main table, when I switch to the Form view and tab
from field to field, when I tab out of any of the combo boxes, I
get the same message. "The value you entered isn't valid for this
field. For example, you may have entered text in a numeric field
or a number that is larger than the field size setting permits."
This is incorrect, the field sizes and types match in every case.
Any ideas?

Do you perhaps have lookups defined in any of your tables? If one of
them is based on a linked table, and you deleted the link, it could
perhaps cause problems like what you've described.

Thanks for your reply. I was taught to never do lookups (10
Commandments), so no, there aren't any in the database.

I'm pretty sure I'm not reading you right, so please reassure me that
you don't mean that you never do lookups or, if you don't, exactly what
you mean by this. Such an instruction has never appeared in any 10
Commandments I can recall.

Edward

[David W. Fenton]

te********@hotmail.com wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:

davegb wrote:

David W. Fenton wrote:

> "davegb" <da****@safebrowse.com> wrote in
> news:11**********************@g14g2000cwa.googlegr oups.com:
>
> > I'm now wondering if the two problems aren't related. Ever
> > since I deleted the mysterious tables, whenever I create a
> > combo box which accesses the main table, when I switch to the
> > Form view and tab from field to field, when I tab out of any
> > of the combo boxes, I get the same message. "The value you
> > entered isn't valid for this field. For example, you may have
> > entered text in a numeric field or a number that is larger
> > than the field size setting permits." This is incorrect, the
> > field sizes and types match in every case. Any ideas?
>
> Do you perhaps have lookups defined in any of your tables? If
> one of them is based on a linked table, and you deleted the
> link, it could perhaps cause problems like what you've
> described.

Thanks for your reply. I was taught to never do lookups (10
Commandments), so no, there aren't any in the database.

I'm pretty sure I'm not reading you right, so please reassure me
that you don't mean that you never do lookups or, if you don't,
exactly what you mean by this. Such an instruction has never
appeared in any 10 Commandments I can recall.

I'm not the person you're asking, but the 10 Commandments referred
to are, I believe, the ones on the Access Web, at mvps.org/access.

One of those commandments is to never define lookup dropdown lists
in table design, which is what is referred to above.

It's a good prohibition as using those lookups leads to all sorts of
problems, and is just a bad idea from a database standpoint.

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

[davegb]

te********@hotmail.com wrote:

davegb wrote:

David W. Fenton wrote:

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:

> I'm now wondering if the two problems aren't related. Ever since I
> deleted the mysterious tables, whenever I create a combo box which
> accesses the main table, when I switch to the Form view and tab
> from field to field, when I tab out of any of the combo boxes, I
> get the same message. "The value you entered isn't valid for this
> field. For example, you may have entered text in a numeric field
> or a number that is larger than the field size setting permits."
> This is incorrect, the field sizes and types match in every case.
> Any ideas?

Do you perhaps have lookups defined in any of your tables? If one of
them is based on a linked table, and you deleted the link, it could
perhaps cause problems like what you've described.

Thanks for your reply. I was taught to never do lookups (10
Commandments), so no, there aren't any in the database.

I'm pretty sure I'm not reading you right, so please reassure me that
you don't mean that you never do lookups or, if you don't, exactly what
you mean by this. Such an instruction has never appeared in any 10
Commandments I can recall.

Edward

I was told about these by Sco Scoville, a database/Access consultant,
former MVP, and trainer I took a custom class from a few months ago.

And it came to pass that the cries and lamentations of the Access
newbies were heard on high by the gods of the Database, and their
hearts were moved to pity for their followers. And they opened their
mouths and spake, saying: "Nevermore shall the young and innocent
wander witless on their journeys! We shall provide guidance to them,
yea, and to all who wish to seek the paths of wisdom." And they caused
these commandments to be written and placed before the eyes of those
seeking enlightenment.So heed the words of those who have come before
you, and keep these commandments in thine heart as thou dost create thy
Database application. If thou shalt only follow these commandments thy
burden shall be made light and thy path shall be made straight.
1. Thou shalt design normalized tables and understand thy fields and
relationships before thou dost begin.
2. Thou shalt never allow thy users to see or edit tables directly, but
only through forms and thou shalt abhor the use of "Lookup Fields"
which art the creation of the Evil One.
3. Thou shalt choose a naming convention and abide by its wisdom and
never allow spaces in thy names.
4. Thou shalt write comments in your procedures and explain each
variable.
5. Thou shalt understand error handling and use it faithfully in all
thy procedures. 6. Thou shalt split thy databases.
7. Thou shalt not use Autonumber if the field is meant to have meaning
for thy users.
8. Thou shalt not copy and paste other people's code without at least
attempting to understand what it does.
9. Thou shalt not use "SendKeys", "Smart Codes" or "GoTo" (unless the
GoTo be part of an OnError process) for these will lead you from the
path of righteousness.
10. Thou shalt back-up thy database faithfully, working not on thy
Production Database, but on the Prototype Copy, as it is right and good
to do. Thus spake the gods of the Database, and blessed be their names!
And Blessed, too, are those who contribute to the Access Newsgroup -
giving freely of themselves to serve those who hunger and thirst for
knowledge and understanding!

2. is the one "forbidding" look-ups.
If you Google for them, I'm sure you can find them on the net. I know
that others besides Sco promulgate these rules.

I don't have enough experience yet with Access to know if these are
totally valid. I do know from extensive experience working with MS
Project, that there are a number of things you "can" do in Project that
anyone who really knows scheduling (like me) would tell you never to
do. Many of them appear harmless to a novice, but as you get into more
advanced applications, they become serious problems, even obstacles, to
getting a meaningful schedule. I try, with mixed results, to steer
beginners away from them so that as their needs grow, they don't have
to relearn how to use the tool and to avoid pitfalls. As a beginner,
it's hard to understand this. So now that I am learning Access, I
accept these, at least for the time being, as valid. At least until
someone, or several someones, gives me a reason to change. I'm smart
enough to know there are people much smarter than me in the world. As a
professional consultant, I see a lot of people who won't take my advice
and get themselves into a lot of trouble. I don't intend to be one of
those who pays an expert to teach me the right way to do something,
then ignore the advice I paid so much for.
And you just received one of my favorite rants, for free! :)
However, I'm open to contrary opinions.

[davegb]

Terry Kreft wrote:

I still think the people who were involved in implementing AutoCorrect in a
database application should be hit soundly with a large bat until they get
the concept of boilerplate.
--

Terry Kreft
Probably even better if you hit them with a piece of boilerplate until
they get the concept of boilerplate...


"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:

<SNIP>

. . . And there are things MS calls "features"
which experienced users call "glitches".

Most of the those in Access are things that were implemented with
the best of intentions to make something easier for novices.

<SNIP>

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

[davegb]

David W. Fenton wrote:

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:

There's underlying theory you have to
understand to make it "go".
It's a database application. Thus, knowing theory of database design
is going to help a lot.

FWIW, most of the Access sample databases are very poorly designed,
schema-wise.

That's good to know.

. . . And there are things MS calls "features"
which experienced users call "glitches".
Most of the those in Access are things that were implemented with
the best of intentions to make something easier for novices.
Unfortunately, these features were not designed very well, and most
of them are better turned off for anyone who wants to progress
beyond the most elementary stage.

Same thing in Project. I don't know what happened in Access, where MS
got their "expertise" to design it, internal or external. But I do know
the genisis of Project, having talked to one of the five high paid
consultants MS hired to show them how to do critical path scheduling.
When all five tried to tell the MS developers that what they were doing
was a gross oversimplification, MS ignored them. At least 80% of the
funcional changes made in Project for Windows since it's inception,
have been to correct the very things those consultants warned them not
to do.

Access is not a program like Word. It's a development platform with
a database engine. That makes it at least an order of magnitude more
complicated than the vast majority of applications that most people
are accustomed to dealing with. This often makes users of simpler
applications think that Access is badly designed, since it's som
complex, but it is as complex as it needs to be for what it is
designed to do, but most people don't have the right expectations,
since most of the apps they've used are of a completely different
type (document-based apps, like Word or Excel).

Every other program that is trying to accomplish the same thing has
copied a great deal from Access, and has exactly the same levels of
complexity as Access. The only one that might be easier in this
regard is FileMaker Pro, but it also lacks the same depth of
complexity in the programming language, as well as lacking the
enormous interoperability that comes from Access having COM built
into it.
It's not the complexity I object to. That's inherent in the
application, whether it's critical path scheduling or database design.
It's the fact that MS, in an supposed attempt to simplify, has built
traps right into the software for a novice, me in this case, to fall
into.
If the software is smart enough to create those linked tables when I
did something wrong, why wasn't it just a tiny bit smarter and give me
an error message explaining why it had automatically created them? And
why are there these other traps like look-ups. It's like luring you
into thinking something is much simpler and easier than it really is to
sell you the product, knowing that down the road the end user is going
to pay in lost time and effort to make the application really work. I'm
just not a fan of this kind of marketing strategy.

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

Thanks for your comments, I find them quite helpful.

[David W. Fenton]

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@o13g2000cwo.googlegr oups.com:

It's not the complexity I object to. That's inherent in the
application, whether it's critical path scheduling or database
design.
But it's the complexity that leads to the desire on the part of a
software company to provide help for people without the training or
experience to be able to cope with that complexity. That's a *good*
impulse on the part of Microsoft (or any other software company).
It's the fact that MS, in an supposed attempt to simplify, has
built traps right into the software for a novice, me in this case,
to fall into.
Well, in certain contexts, the shortcuts for the novices *don't*
cause problems, so it's hard to fault MS for putting them in, since,
within the limited scope of their intended use, they function fine.

Access itself is often criticized for not being something it was
never intended to be, so I can't get too worked up about some of
these features that are implemented to help within some limited sets
of circumstances.

It's when the features are implemented in a buggy way that I have a
problem.
If the software is smart enough to create those linked tables when
I did something wrong, why wasn't it just a tiny bit smarter and
give me an error message explaining why it had automatically
created them? And why are there these other traps like look-ups.
It's like luring you into thinking something is much simpler and
easier than it really is to sell you the product, knowing that
down the road the end user is going to pay in lost time and effort
to make the application really work. I'm just not a fan of this
kind of marketing strategy.

Well, I suspect that if your problem was related to AutoCorrect,
that what actually happened was some kind of catastrophic bug that
caused a complete failure of the system. It's hard to build anything
that can recover from a complete breakdown like that.

But I saw that I didn't need or want Name AutoCorrect the first time
I opened and Access 2K database -- *I* want to be in control of when
object names change, not some behind-the-scenes operator that I
can't control.

Now, if they'd implemented it with some kind of granular control
over which things it propagates name changes to, and allowed
granular control of when you'd get prompted, and incorporated some
kind of backup so that it could be easily reversed if it caused a
problem, now *then* it would be a useful feature.

But my guess is that this would be too complicated for most people
to use. Nonetheless, programmers would be able to use it, and it
could be set with defaults that would make it universal with no
prompts, as it actually was implemented, but allowing for those who
are smart enough to use it with more control.

They didn't implement it that way, so I won't use it.

I believe there's a conflict between MS's product engineers and
their marketing department sometimes, too. A perfect example
(similar to your description of the designers of MS Project) of
where I would guess a software engineer on the Access team probably
resisted the implementation of a MS Office-wide feature was the
standard AutoCorrect function (not Name AutoCorrect, but the
AutoCorrect that replaces i with I when you're typing in Word) that
is applied by default to *all* controls on an Access form. This
might make sense as an optional function for text fields, but it is
completely brain-dead stupid to have it even available at all for
combo boxes, which are designed for the sole purpose of restricting
data entry to a set of pre-defined choices. Any control type that
has that purpose should *never* be subject to data entry changes
from some outside function that is actually not controllable by the
database application programmer.

It was just dumb.

And I am as certain as one can be that the Access project managers
told the Office team that it was bad design since they know
perfectly well that such a feature has no place in a database
application. But they were overridden, nonetheless.

The surprising thing when you think about it is that so many Access
apps created by novices using these less-than-good features still
function perfectly reliably, and have value for the people who use
them.

Access is pretty indestructible, seems to me.

And that's one of the reasons it's so dangerous -- it tolerates too
much suboptimal design.

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

[davegb]

David W. Fenton wrote:

"davegb" <da****@safebrowse.com> wrote in
news:11**********************@o13g2000cwo.googlegr oups.com:

It's not the complexity I object to. That's inherent in the
application, whether it's critical path scheduling or database
design.
But it's the complexity that leads to the desire on the part of a
software company to provide help for people without the training or
experience to be able to cope with that complexity. That's a *good*
impulse on the part of Microsoft (or any other software company).

It's the fact that MS, in an supposed attempt to simplify, has
built traps right into the software for a novice, me in this case,
to fall into.

Well, in certain contexts, the shortcuts for the novices *don't*
cause problems, so it's hard to fault MS for putting them in, since,
within the limited scope of their intended use, they function fine.

Access itself is often criticized for not being something it was
never intended to be, so I can't get too worked up about some of
these features that are implemented to help within some limited sets
of circumstances.

I appreciate your comments, Dave, but I disagree here. I think that
putting in "shortcuts" that make it easier if you don't know anything
about the subject, but create serious problems for those that do, is
poor design. This Name Autocorrect "feature" has cost me time and been
a distraction from getting the database done. Features should work all
the time or not be there at all. I believe than inconsistency is a
major flaw in any software.
There is a similar "feature" in Project which, under certain
circumstances, creates "links" between tasks automatically. Most
beginners would hardly notice. But when I finally figured out that it
was happening, it took me an hour and a half to track down how to turn
this feature off. It was sabotaging my efforts. Now I warn my students
to turn this feature off if they want to have any hope of creating
meaningful schedules. I don't think this is good design, no matter how
well-intentioned it is.


It's when the features are implemented in a buggy way that I have a
problem.
I agree here. Just making matters even worse!

If the software is smart enough to create those linked tables when
I did something wrong, why wasn't it just a tiny bit smarter and
give me an error message explaining why it had automatically
created them? And why are there these other traps like look-ups.
It's like luring you into thinking something is much simpler and
easier than it really is to sell you the product, knowing that
down the road the end user is going to pay in lost time and effort
to make the application really work. I'm just not a fan of this
kind of marketing strategy.
Well, I suspect that if your problem was related to AutoCorrect,
that what actually happened was some kind of catastrophic bug that
caused a complete failure of the system. It's hard to build anything
that can recover from a complete breakdown like that.

Actually, it wasn't a catastrophic failure. Everything worked fine
until I deleted the automatically created linked files to correct for
my error (I am know to be a bit impulsive at times. And knew I could
recover if I had to.). I was impressed that it did that, just annoyed
that it didn't give an appropriate error message when it created the
special files. Even more annoyed that this is a known problem that
probably should have been fixed several versions back.

But I saw that I didn't need or want Name AutoCorrect the first time
I opened and Access 2K database -- *I* want to be in control of when
object names change, not some behind-the-scenes operator that I
can't control.

Now, if they'd implemented it with some kind of granular control
over which things it propagates name changes to, and allowed
granular control of when you'd get prompted, and incorporated some
kind of backup so that it could be easily reversed if it caused a
problem, now *then* it would be a useful feature.

But my guess is that this would be too complicated for most people
to use. Nonetheless, programmers would be able to use it, and it
could be set with defaults that would make it universal with no
prompts, as it actually was implemented, but allowing for those who
are smart enough to use it with more control.
MS has to recognize that their software has users at all levels of
expertise, and that some users just ain't gonna get it, not matter how
simple they try to make it. I don't like the paradigm of designing in
"ease of use" features for the beginner (and may undermine their
understanding of how the process actually works) that sabotage the
expert.

They didn't implement it that way, so I won't use it.

I believe there's a conflict between MS's product engineers and
their marketing department sometimes, too. A perfect example
(similar to your description of the designers of MS Project) of
where I would guess a software engineer on the Access team probably
resisted the implementation of a MS Office-wide feature was the
standard AutoCorrect function (not Name AutoCorrect, but the
AutoCorrect that replaces i with I when you're typing in Word) that
is applied by default to *all* controls on an Access form. This
might make sense as an optional function for text fields, but it is
completely brain-dead stupid to have it even available at all for
combo boxes, which are designed for the sole purpose of restricting
data entry to a set of pre-defined choices. Any control type that
has that purpose should *never* be subject to data entry changes
from some outside function that is actually not controllable by the
database application programmer.

It was just dumb.

And I am as certain as one can be that the Access project managers
told the Office team that it was bad design since they know
perfectly well that such a feature has no place in a database
application. But they were overridden, nonetheless.
Sounds like a case of a company-wide edict, "make all Office programs
compatible in these areas", overriding common sense in one package.
Unfortunately, happens all the time in big business.

The surprising thing when you think about it is that so many Access
apps created by novices using these less-than-good features still
function perfectly reliably, and have value for the people who use
them.

Access is pretty indestructible, seems to me.

And that's one of the reasons it's so dangerous -- it tolerates too
much suboptimal design.

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

Years ago I worked with a scheduling software package that gave the
user the option of 3 levels of menus, Beginner, Intermediate, Expert. I
liked that feature. I think it has merit in these situations we're
talking about here. But I'm never a fan of automating to the point
where it becomes difficult for knowledgeable users to use the software
following established best practices in the field. MS seems to do this
consistently. In the case of Project, I know it was due to a
combination of arrogant and ignorance (I met the Project Lead face to
face). I don't know why it happened in Access, but I'm mistrustful
based on my experiences on Project and with MS in general.