Hi Graham,

Yes, I run Access 2000 at home. We have access 2003 at work and I just
found the right settings on that one. I'll keep away from it anyway,
but its nice to know where the option is if I ever need it.

By the way, I think I found a slight bug in the Before_Update code you
supplied. What I have found is if I try to change the ContactType the
custom error message popups up as expected. If I then opt to delete
the existing record, everything is fine. The record is deleted and I
can still navigate the records using the record selector at the foot of
the main (Clients) form - again everything works as expected. But if I
opt to cancel the update instead, I end up getting the standard Access
message about not being able to change or delete the record (ie the one
I was getting before you came to the rescue :-) ).

I came to the conclusion that the "cboContactType.Undo" line simply
wasn't working. After looking in the help files on the "dirty" event,
I noticed this statement:

"The BeforeUpdate and AfterUpdate events for a record occur after you
have entered the new or changed data in the record and moved to another
record (or clicked Save Record on the Records menu), and therefore
AFTER the Dirty event for the record." (my emphasis)

So I focussed on the dirty event. Anyways, for the benefit of those
who might have been following this thread, I resolved the problem by
simply adding "Me.Form.Undo" in the line immediately after the existing
undo command.

These variations also worked ("Clients" is the name of my main form):

(1) Forms!Clients.Undo

(2)
If Forms("Clients").Dirty = True Then
Forms("Clients").Undo
End If

Everything seems to be fine now. Thanks again for all your help on
this issue.

Getting back to the ADO/DAO, my long term aim would be ultimately to
port my little Access program to VB.Net - purely because I'm a sucker
for punishment :-)

If I code everything using DAO now, will I need to re-code everything
into ADO later, or does VB.Net not care which one you reference?

On a different tangent, if I port everything over to VB.Net, do you
know if I will need extra licences or if I have to upgrade to a
developer edition of some sort before I can distribute my VB.Net
program with an .mdb file? Will my VB.Net or existing ms office
licences cover this sort of thing (ie distribution)? And what's the
deal with runtime files? Will they be packaged with my .mdb file if I
incorporate that into a VB.Net program?

Thanks for letting me pick your brain.


TIA
Bob



Graham Mandeno wrote:

It sounds like you're using Access 2000, which does not have this option.
(This would also explain why your VBA references were set to ADO by default,
and not DAO)

You don't want SQL-92 anyway, if you are working with a Jet database.
--
Cheers,

Graham Mandeno [Access MVP]
Auckland, New Zealand

"Bob" wrote in message
...
Hi Graham,

Actually I did have another question too - more out of curiosity than
anything else.

You mentioned earlier that to switch to ANSI-92 mode you need to go to
Tools
Options Tables/Queries. When I following these directions I get a
form
with a Table and a Query design section. In the Table design section, I
get options to change the default field sizes, the default field type, and
a box for "AutoIndex on Import/Create". In the Query design section, I
get checkboxes to "show table names", "output all fields" and "enable
autojoin". I also get radio buttons to "Run permissions" as "Owner's" or
"User's". But I don't see anything that refers to ANSI mode. Any ideas
why?


Regards
Bob

"Bob" wrote in message
...
Whoo Hoo!

Thanks alot Graham. It's finally working. :-)

Just one more question though, why do you prefer DAO over ADO? I've now
acquired a copy of the "Microsoft Office Access 2003 Bible" and there's a
small section in it that asserts that ADO is to be preferred over DAO
because Microsoft does not plan to provide any future enhancements for
the latter. I'm still starting out at this, so I'm not entirely clear on
the other pros and cons of each.


Regards
Bob