We have an Access front-end with a SQL Server back-end. I have
written my own module to identify all object dependencies. However,
it only works with tables which are not linked to our SQL Server back-
end. Why? And is there any way to get around this? Thanks!

hi,

(E-Mail Removed) wrote:
> We have an Access front-end with a SQL Server back-end. I have
> written my own module to identify all object dependencies. However,
> it only works with tables which are not linked to our SQL Server back-
> end. Why?
How could we know? No code, no answer...



mfG
--> stefan <--

On Mar 26, 2:39*pm, Stefan Hoffmann <ste...@ste5an.de> wrote:
> hi,
>
> linton.mccrac...@gmail.com wrote:
> > We have an Access front-end with a SQL Server back-end. *I have
> > written my own module to identify all object dependencies. *However,
> > it only works with tables which are not linked to our SQL Server back-
> > end. *Why? *
>
> How could we know? No code, no answer...
>
> mfG
> --> stefan <--

When I asked my supervisor about this he said that Access cannot
examine objects outside of the database, including the inability to
examine objects linked to an Enterprise SQL Server. The reason for my
post was to get confirmation of my supervisor's statement, ask why
this is, and inquire if there are any ways to get around this
limitation.

hi,

(E-Mail Removed) wrote:
>>> We have an Access front-end with a SQL Server back-end. I have
>>> written my own module to identify all object dependencies. However,
>>> it only works with tables which are not linked to our SQL Server
>>> back-end. Why?
>> How could we know? No code, no answer...
> My IT supervisor told me that Access cannot examine objects outside of
> Access, thus it can't examine objects that are linked to an outside
> SQL Enterprise Server.
Access can examine _every_ object outside of Access as long as this
object provides public interfaces of any kind.

> My post here was to get confirmation of my
> supervisor's statement, and inquire about why this is the case, and if
> there is any way that Access 2003's object dependency functionality
> could examine a "foreign" object.
Especially it can work with SQL DMO / SQL SMO (depending on the SQL
Server version). These are APIs for working with SQL Server objects of
any kind.

http://support.microsoft.com/kb/822642/
http://msdn.microsoft.com/de-de/library/ms162169.aspx

Otherwise these APIs are often not necessary, as SQL Server offers a
whole bunch of system views, a lot of them are located under
INFORMATION_SCHEMA:

http://msdn.microsoft.com/en-us/library/ms186778.aspx
http://msdn.microsoft.com/en-us/library/ms177862.aspx

My answer in short normally would be: Your supervisor is completly wrong.

BUT: You're using the term "Access 2003's object dependency functionality".
This is not an offical term or a term in wide spread use. I never heard
it. What do you mean?
On behalf of this, your supervisor may be right. This "functionality"
may be not capable of solving your problems.

So, my first answer is still valid: No code, no answer.

Take a look at the links, be so kind to provide at least code samples
and an real outline of your goals. Otherwise any advice or discussion is
based on guesses.


mfG
--> stefan <--