topic Re: Layer not found in Data Management Questions

Layer not found

Udaya_BhaskerCheerala — Thu, 04 Jul 2013 11:06:30 GMT

Dear All,

We have developed a desktop application usin ArcSDE C API, which reads latitudes and longitudes
from SQLServer 2008 database and creates points in the SDE feature class. Previously it was in
ArcSDE 9.1, now we migrated this application to ArcSDE 10.0.

Everything works fine when ArcSDE 10.0 and SDE Geodatabase is in same machine, if I move
SDE Geodatabase to some other machine i.e. if I place ArcSDE in one machine and SDE database
in another machine. Iam getting error "Layer not found (-20)". But connection to databse is successful.

What could be the reason?

Thanks,
-U

Re: Layer not found

VinceAngelo — Thu, 04 Jul 2013 13:44:59 GMT

There's been a great deal of changes between releases 9.1 and 10.0 -- I doubt
your application is necessary any more (you can just create a trigger to insert
[or update] the GEOMETRY when the lat/lon values are created [or changed]).

If you really want us to debug your code, you'll have to provide it (or preferably,
the smallest subset which exhibits the behavior). You'll also need to provide
'sdelayer -o describe_long' and 'sdetable -o describe' output for all of the
tables involved, as well as the user which is used to execute the app (if it's
not the owner [and it shouldn't be]).

You should also experiment with Direct Connect connection syntax, to see if it
makes a difference (it will also save you on licensing and processing overhead
costs).

- V

Re: Layer not found

Udaya_BhaskerCheerala — Fri, 05 Jul 2013 13:08:10 GMT

Vince,

Thankyou very much for the quick reply. My problem is solved by passing the fully qualified Layer Name like "SDE.LayerName".

Thanks for your support.

Thanks,
-U

Re: Layer not found

VinceAngelo — Fri, 05 Jul 2013 13:24:54 GMT

All applications should always use fully-qualified table names.

The SDE user should not ever own spatial data. That login should be reserved
for ArcSDE instance management. Best practice is to create one or more user
accounts to own the data, and at least one more for any applications which use
the data (web applications should never connect with the user that owns the data,
lest you open yourself to a denial-of-service attack which drops the tables).

- V