Latest Contributions by VinceAngelo

This doesn't have to do with the FileGDB API so much as Visual Studio/Windows software development.  Esri ships two libraries, the link library in lib, and the runtime library in bin.  The link library is just a set of stubs so the compiler knows the DLL function signatures, and the runtime library contains the actual file geodatabase functions. Actually, it's a bit more complicated than that, because Esri ships three different API implementations for Windows, for Visual Studio 2010, 2012, and 2013, and each of them have both 32-bit and 64-bit libraries, and each of those have DEBUG and NDEBUG builds.  And then there's the C# library, Esri.FileGDBAPI.dll, with one wrapper library per application word-size per compiler environment.  And the matching PDB files, of course. (And there's 32-bit and 64 bit Linux releases, and GCC and CLANG MacOS releases.) As a software developer, you should not ever need to ship FileGDBAPID.dll, since the larger, slower debug libraries aren't of much use in production environments, so only FileGDBAPI.dll needs to be copied into the bin folder of your application (from bin or bin64, depending on which way you've compiled your application).  For local testing purposes, you can include the runtime distribution folder in your local PATH, but it's best practice to test out of your application's bin folder, so you don't have to deal with runtime link issues later in the production chain. The location for those libraries is dependent on the location to which you've extracted the API zipfile, so we can't help you on that score.  I would recommend that you set an environment variable for the File Geodatabase API home (e.g. FGDBAPI_HOME), so that you can use that environment variable in your VS projects -- in this way subsequent releases don't require rewriting all your project parameters.  Visual Studio allows for command execution after successful compile (the "Post-Build" event in "Build Events"), so you can even automate the process of copying both your compiled binary and the runtime DLL into a BAT script if you choose (the details for that are off-topic here). - V BTW: GeoNet doesn't use gis.stackexchange.com formatting techniques, so duplicate cross-posts are not going to look the same. ... View more

Part of the issue is a thorough understanding of how databases work.  I realize it's hard to step in to some other admin's shoes, but Esri can't provide all the pieces in the learning curve.  I strongly recommend you find a book or class in SQL-Server administration. For the record, it appears that you have an 'SDE' database (SQL-Server manages many databases within the RDBMS instance).  The full name of  any table in a RDBMS that supports independent databases (which is all of them, as of Oracle 12c) is in the form database.owner.tablename.  Databases almost never reference filenames, especially in table names, so the "SDE.filename.yadayadayada" reference is really owner "filename" and table "yadayadayada" in database "SDE". It is true that it is against best practice to name the database "SDE", but that shouldn't prevent you from accessing the data. What could prevent such access is the security model of the database -- by default users can't see tables owned by other users unless they have been explicitly granted this access, either to the user, or to a role to which the user belongs (see the GRANT directive). In addition, ArcGIS enterprise geodatabases require that table owners have a schema name which is identical to the username within the database (it's a neat capability for a user to wear a different nametag in every database, but it leads to fiendishly complex (and slow) metadata queries to support tables which have a schema other than the owner username).  Non-owners who have a schema which does not match username should be able to access tables owned by users whose schema does match, though there may be quirkiness when working with selection sets of more than 1000 rows in a table. There is no solution to the schema/owner requirement, but it's rarely a bad idea to re-implement a geodatabase using best practices during the transition of geodatabase administrators.  Unfortunately, learning best practice is not a short-term goal, so it might be necessary to use what is already in place a while, taking notes on what may be needed later in the transition process.  You'll also be well-served by establishing a working rapport with the IT team with respect to GIS database administration -- sometimes it's just as critical to get some understanding of GIS issues at the IT level as it is in gaining database admin skills at the GIS level. - V ... View more

Why do you need the non-spatial view registered with ArcSDE? There aren't many use cases that require this. Any table or view can be registered with ArcSDE with: sdetable -o register -t tablename -C USER -c rowidcolumn -i sde:... -D ... -u ... -p ... But if there isn't any pressing reason to do so, I would recommend against it. - V ... View more