There is a problem with not null constraints and Mapguide Enterprise. This problem exists in both 2008, and the 2009 versions. If any columns within your table or view are defined as not allowing null Mapguide will pick these up as key fields.
I found this problem when trying to programmatically retrieve a feature set of the current selection. When the SetFilter method on the MgFeatureQueryOptions call was issued I was receiving a "Not Implemented" error. After a bit of back and forth with Steve Dang at Autodesk he gave me a list of valid database property types for the SetFilter call:
This got me looking at my underlying fields, and eventually I noticed in the ODBC data connection the key fields for the table in question contained a number of columns that just should not have been there. The problem field was a date column – which would explain why the SetFilter call was throwing and error. Upon closer inspection I realized that these columns were constrained with "Not Null" constraints.
So I changed my source database and removed the not null constraints. Went back to studio to refresh the table – but the columns were still there. Long story short – there is possibly another defect somewhere in Mapguide around data connections. They seem to not fully update when you make changes to them. However, creating a new data connection and pointing to the same SQL server database now shows keys without the null columns.
Moving forward in my code now generated the selection filter and things were good.
I proposed to Autodesk that they auto populate the key fields but then allow the user to modify this list, in addition to correcting the not null constraint issue. It seems as though all primary and foreign keys are being found for the table/view and added to the list. Fair enough, however in the view I was working with I had something like 10+ keys (due to the joins of data tables, as well as the needed lookup tables). In reality – I only was interested in one of those fields. Filtering based on that one field was enough to uniquely identify the data in question. I’m not really familiar with the way FDO does things so this might not be possible.