Layer not found

1370
3
07-04-2013 04:06 AM
Udaya_BhaskerCheerala
New Contributor
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
0Kudos
3 Replies
VinceAngelo
Esri Esteemed Contributor
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
(或更新)的几何当纬度/经度值re 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
0Kudos
Udaya_BhaskerCheerala
New Contributor
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
0Kudos
VinceAngelo
Esri Esteemed Contributor
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
0Kudos