Hi,
I’ve been working with File GeoDatabases recently and am finding problems with using the GetTableNames() method of the FileGeoDatabaseFeatureLayer class.
Basically, I am finding that the results returned are not always GeoDatabase feature classes. Depending on the structure of the GeoDatabase, it can return a feature dataset object (which is a collection of feature classes) which then ignores the underlying feature classes or a data table which by definition doesn’t contain features to examine. Attempting access to the feature source of any of the returned table names from the GetTableNames() method which are not feature classes inevitably returns errors. And additionally I end up missing key tables when trying to examine a feature dataset object mistaken as a table.
The following document standard shows this structure on page 9.
geobc.gov.bc.ca/common/specs…ndards.pdf
Additionally, I have attached an image that shows these types for a database I am currently working with. In this example, the GetTableNames() method mistakenly returns CULTURE as a table and none of the items found in it. Unfortunately, the data is proprietary so I can’t provide a sample. I would be happy to do a net meeting though to demonstrate.
I would request that GetTableNames() method returns only the feature classes and recursively looks into feature datasets for additional feature classes. I have already confirmed that I can manually plug-in table names for tables existing within feature datasets and read their data. I just need a reliable method to return all feature classes in a GeoDatabase.
Thanks,
Damian
ArcCatalog_Example.png (39.8 KB)
File GeoDatabase Get Tables Method Returns Datasets
Hi Damian,
Thanks for reporting this, we have recreated your problem, but it will need a little bit time to sort it out, would you please wait a little while for it?
Best Regards
Summer
Thanks Summer. Glad it was easy to identify. Let me know when a fix is in place.
Regards,
Damian
Hi Damian,
Would you please get the new wrapper, then replace the dlls in “C:\Windows\SysWOW64\Map Suite 7.0\FileGeoDatabaseX64” and “C:\Windows\SysWOW64\Map Suite 7.0\FileGeoDatabaseX86” with the new ones and try it again, it should work now.
If you have any more question , please feel free to let us know.
Best Regards
Summer
newWrapper.zip (29 KB)
Hi Damian,
Would you please get the latest dll package from you customer portal and find the FileGeoDatabase wrapper(FileGdbApiWrapperX64.dll and FileGdbApiWrapperX86.dll) , then replace the dlls in "C:\Windows\SysWOW64\Map Suite 7.0\FileGeoDatabaseX64" and "C:\Windows\SysWOW64\Map Suite 7.0\FileGeoDatabaseX86" with the new ones and try it again, it should work now.
If you have any more question , please feel free to let us know.
Best Regards
Summer
Hi Summer,
It appears that there is something wrong with the customer portal (or my login). When I go in and look at the daily production and development builds, I see versions 6.0.353.0 and 7.0.0.28 respectively. I’m at 7.0.0.42 right now, so something isn’t right. See images below.
Supposing that it is corrected sometime today, exactly what version should I be looking for? Is it production or development?
Regards,
Damian
Hi Damian,
Sorry for the inconvenience, maybe when you were checking the customer portal, the new dlls were still in build, now we checked again, and now 7.0.30.0 is available, would you please check it again?
please install the new "MapSuite Unmanaged Dependencies" in dlpackage the new FileGdbApiWrapperX64 and FileGdbApiWrapperX86 will be installed automatically.
Hope it helps
Summer
Hi Summer,
I managed to get 7.0.0.30 off the customer portal and ran the unmanaged dependencies installer. It asked if I would like to repair or remove. I chose remove in hope it cleared out the previous stuff and then ran it again. And, I am now using 7.0.0.30 libraries in my project. However, there is no difference to the tables returning from the GetTableNames() method.
When I look at the SysWOW64\Map Suite 7.0\FileGeoDatabaseX86 directory and then get properties of the FileGdbApiWrapperX86, I see the following.
So, it looks like the unmanaged dependencies are either not updated in the package or it failed to update anything when I ran it.
Please advice.
Thanks,
Damian
Hi Damian,
Thanks for reporting this and sorry for that we made a mistake of not synchoronising the new wrapper to release build, now it has been synchronized to the wrapper, would you please the the new dlls 7.0.0.32 or 7.0.32.0 and try it again?
Sorry for the inconvenience.
Summer
Summer,
This is getting ridiculous. I’ve pulled over 7.0.0.32 and there is still no change to the dll’s installed by the unmanaged dependencies msi installer.
To summarize the past week:
- July 2nd I reported the daily production build was actually 7.0.0.42 and no one said a word. How did that happen?
- The first time you asked me to download earlier this week, there were actually entries for version 6 in the customer portal per my screen captures above.
- Yesterday when I first logged in, the version 6 items were back again.
- Yesterday when the distribution script finally kicked in, the build 7.0.0.30 had incorrectly packaged installers.
- Today the build 7.0.0.32 has the same incorrectly packaged installers.
There are obviously some issues with the daily build scripting. Please report this immediately to the distribution team and make sure they sort their issues out before asking me to download anything else.
Damian
Hi Damian,
First of all, really sorry for the trouble we have made in the past week.
I have confirmed with the distribution team, and the root has been found, the update in the filegeodatabase wrapper is not included in the unmanaged dependencies msi, we have fixed it, now "Map Suite Unmanaged Dependencies 7.0.0.35" or "Map Suite Unmanaged Dependencies 7.0.35.0" will be the right version(still in build, will be available in hours).
Here is a result image on our end for your information:
About GetTableNames, we now are using
results.AddRange(geodatabase.GetChildDatasets("\\", "Feature Class"));
results.AddRange(geodatabase.GetChildDatasets("\\", "Table"));
to filter to get the "Feature Class" and "Table" and the "feature Dataset"(Culture) should not be included now.
really sorry
Summer
Hi Summer,
I can confirm that with 7.0.0.35 I no longer get errors when trying to import the previous “Wells_GMX” layer. Thanks.
Unfortunately, when I run FileGeoDatabaseFeatureLayer.GetTableNames(), I still get the same list as before. Perhaps the build 7.0.0.35 just has the updated unmanaged dependencies installer, but doesn’t include your changes above? If I understand correctly, I shouldn’t have to reference anything other than MapSuiteCore to run this command.
I do see a new dll in FileGeoDatabaseX86 and X64 as well, but the version number is still 1.0.0.0. It would be great for tracking purposes if this number got updated to match the current build of the managed dependencies. It would be less confusing that way.
Regards,
Damian
I’m sorry Summer, I have to restate my post.
In fact, the list is now different in that it no longer returns the feature dataset names which is good. But, it still does not return any of the Feature Classes or Tables within the dataset names.
The only returns I get are from the Feature Classes and Tables that are at the root level.
If indeed you are querying each dataset, it seems you may be reinitializing the results somewhere along the way.
Regards,
Damian
Hi Damian,
As we don't have data that contains Feature dataset, so, Would you please replace the attached filegeodatabase wrappers dlls with the old in "C:\Windows\SysWOW64\Map Suite 7.0\FileGeoDatabaseX86" and "C:\Windows\SysWOW64\Map Suite 7.0\FileGeoDatabaseX64" to make a test, would you please test some other function like get the features in feature class in feature dataset, if they are ok, we will put them on customer portal for customers to download.
Waiting for your further information.
Summer
dll.zip (28.3 KB)
Thanks Summer,
It looks like this is working well now. And, it’s an added bonus that you are returning the dataset name as part of the path.
Please let me know which release version I need to upload when it’s available.
When I want to make an installation of my program with these features to give to other users, I suppose I need to include the FileGdbApi dll files somehow. I looked on the deployment guide and it mentions 2 merge modules for these features. I take it I just need to add those merge modules to my installer package? I guess I need to wait until you have the new release as I imagine the merge modules get updated when I run the unmanaged dependencies msi? Sorry for the basic questions, but I’ve not required any of the additional dependencies before now.
Thanks,
Damian
Hi Damian,
Great to hear it works!
About "I take it I just need to add those merge modules to my installer package", actually, the mergemodules are:
Microsoft_VC100_CRT_x64.msm
Microsoft_VC100_DebugCRT_x64.msm
Microsoft_VC100_CRT_x86.msm
Microsoft_VC100_DebugCRT_x86.msm
MapSuiteFileGeoDatabaseX64.msm
MapSuiteFileGeoDatabaseX86.msm
Rather
Microsoft_VC100_CRT_x64.msm
Microsoft_VC100_DebugCRT_x64.msm
Microsoft_VC100_CRT_x86.msm
Microsoft_VC100_DebugCRT_x86.msm
about the newest mergemodules "MapSuiteFileGeoDatabaseX64.msm" and "MapSuiteFileGeoDatabaseX86.msm", would you please contact your account rep, he will provide you the latest mergemodule "MapSuiteFileGeoDatabaseX86.msm" and "MapSuiteFileGeoDatabaseX64.msm"
Best Regards
Summer
I pulled 7.0.0.38 this morning and it still has the old 7.0.0.35 unmanaged dependencies.
Regards,
Damian
Hi Damian,
Sorry for the missing telling about "Umanaged Dependencies Msi". The new "Umanaged Dependencies Msi" will be available in 7.0.43.0 and 7.0.0.43.
Hope it helps
Summer