ThinkGeo.com    |     Documentation    |     Premium Support

ShapeFileFeatureSource Data Type of Columns

#1

MapSuite Team,

MapSuite V10 is acting differently than V9 in getting a collection of columns names and their corresponding data types.

Under V9 the following code would return System.Data.Data Table, which would contain a collection of all columns names and their data types. When doing this under V10 it returns the same collection, but all data types are specified as string, when in fact some of them should be double. I attempted using GeoDataTable, but the collection returned only contains the column name and nothing else. Why was this behavior changed from V9 to V10?

System.Data.DataTable dtColumns = TheFeatureLayer.FeatureSource.ExecuteQuery(“Select * FROM [shapefile.dbf] Where 1=0”);

In V9 the ExecuteQuery returns System.Data.DataTable. In V10 the ExecuteQuery returns GeoDataTable. This is a fairly large change to have been introduced.

Is there another query that will return what it did in V9?

Your thoughts/suggestions please?

Regards,
Dennis

#2

Hi Dennis,

Yes that’s the change we introduced in V10, the reason of the change is because our V10 is be designed as a portable version, we need to make sure the return value of API is a simple type for example string, that’s why we modify the DataTable to GeoDataTable.

Could you please let us know your scenario? So we can give you some suggestion or workaround. In fact I think you can try to convert the string to its original data by your code, because even we help you to do it we still need to do the same convert work.

Regards,

Ethan

#3

Ethan,

Thank you for the explanation. I certainly appreciate ThinkGeo’s desire to make the product portable. I also work to make my company’s product portable, but that portability is now broken and must be fixed.

It would have been nice if GeoDataTable had at least returned similar information as what is found in DataTable, especially type and length. Even introducing a new method would have been preferable and then maintaining the old one.

Having said that, I will recode making use of the information returned from ***TheFeatureLayer.FeatureSource.GetColumns()***. Unless you have another suggestion that I’ve not considered?

Thanks,
Dennis

#4

Hi Dennis,

Our developer discuss about it today, we suggest you choose the GetColumns way for now, because if we modify the API the solution should be replace string to GeoColumns in GeoDatatable, which is not so friendly than the result from GetColumns, and there are some other reasons in code to stop us modify it now, we maybe will modify it in future when we get a better solution about this API.

If you still met problem when you choose GetColumns, please let us know, we can did some further research about this problem.

Regards,

Ethan

#5

hi Ethan,

Thank you for the suggestion to use GetColumns. I will give that a go.

Dennis

#6

Hi Dennis,

I am glad to know that’s helpful, any question please let us know.

Regards,

Ethan

#7

Ethan,

I recoded the section of my application to make use of GeoDataTable and GetColumns. It took almost a day to accomplish, but is now successful.

Thanks for your assistance.

Dennis

#8

Hi Dennis,

Thanks for let us know that, and this post should be helpful if someone else met the same problem.

Regards,

Ethan