Re: SourceTableName truncate
- From: "David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx>
- Date: Mon, 20 Feb 2006 14:54:45 -0600
"Anthony England" <aengland@xxxxxxxxxx> wrote in
news:dtc4k8$mdb$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
This is always a possibilty but in general you are advised against
using MSysObjects directly. While the DAO and ADO object
libraries are provided for programmers to use, MSysObjects is not.
You have no guarantee that code which currently works will
continue to work - changes may be made to this system table which
are beyond your control. Having said that, I think you would be
fairly safe with this one, especially if you put in appropriate
error handling. However, I'm not sure what advantage you hope to
gain over the first function I proposed.
MichKa actually disagrees with this position somewhat in regard to
Jet:
http://trigeminal.com/usenet/usenet017.asp?1033
He describes Microsoft's policy on how these things work, that
nothing that any feature in any past version of Access depends on
will ever be changed, and outlines the kinds of things in system
tables that you can depend on.
By MichKa's formulation, this is one case where you'd be fine
relying on looking in MSysObjects directly, as by MS policy,
anything that's been implemented there is not going to be altered in
future versions of Access.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.
- Follow-Ups:
- Re: SourceTableName truncate
- From: Anthony England
- Re: SourceTableName truncate
- References:
- Re: SourceTableName truncate
- From: david epsom dot com dot au
- Re: SourceTableName truncate
- From: Sean Howard
- Re: SourceTableName truncate
- From: Anthony England
- Re: SourceTableName truncate
- Prev by Date: Multipy Entries tying to same reference table
- Next by Date: Re: Custom Collection Class woes
- Previous by thread: Re: SourceTableName truncate
- Next by thread: Re: SourceTableName truncate
- Index(es):
Relevant Pages
|