[mapguide-users] RE: SQL Server 2008 views and fdo again

[Brent Robinson]

Hi,

That's strange that the primary key is not getting picked up in the first example. It would be a provider defect if table primary key is ignored when the view columns have the same names as the table columns. Could you create a trac ticket for this one; and attach a script for creating the table and view? The table doesn't need to be populated; the schema should be enough to determine what's going on.

I'm not familiar enough with MapGuide to give a definite answer as to why the select needs a primary key, other than to say that at some point it must have to be able to uniquely identify the feature, which would be stating the obvious. Removing the reliance on primary key would be worth looking into, especially if other products are able to do this. My guess would be that some of them are doing one of the following:

	Adding their own unique identifier columns to the feature tables, which would effectively add an
	implicit key. Some of the Autodesk GIS products, such as AGDS and Topobase, use this method. 
	It would not be an option for MapGuide since it needs to be able to handle existing schemas 
	without making modifications to them.

	Use RDBMS-specific system identifiers ( e.g.: rowid in Oracle). FDO and MapGuide might be able to 
	take advantage of these, though some design work would be required to decide on the level of 
	exposure for these identifiers.

	When there is no primary key, default the identity to all non-blob properties. This would work in 
	most cases but would not be guaranteed to provide every feature with a unique identity. 

If there are other methods in addition to the above, these would certainly be worth exploring.

Brent.

-----Original Message-----
From: mapguide-users-bounces at lists.osgeo.org [mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of carc
Sent: Tuesday, February 23, 2010 6:42 PM
To: mapguide-users at lists.osgeo.org
Subject: [mapguide-users] RE: SQL Server 2008 views and fdo again


Hi Brent,

Thanks for the info as that does fill in a lot of the missing pieces
especially in terms of the why.

In the example I provided tableA does have a primary key and this did not
seem to help.

Right now the single table views only work if the view itself contains a
unique, clustered, primary key which now that I reread your post seems
contradictory to what you stated.

Once we have the client upgraded to FDO 3.5 we will try using a clustered
pk, index on a view that contains multiple tables to see if that works.

One question to satisfy my curiosity and that has had me stumped about this
whole issue; why the need for a PK at all in order to do a select against
individual features? Maybe the answer is more complicated then can be easily
explained here but i have used what feels like countless gis data
sources/format/providers and this is the first time I have come across this
requirement. Like I said more a curiosity question then anything.

Thanks,

C
-- 
View this message in context: http://n2.nabble.com/SQL-Server-2008-views-and-fdo-again-tp4273589p4622676.html
Sent from the MapGuide Users mailing list archive at Nabble.com.
_______________________________________________
mapguide-users mailing list
mapguide-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-users