You can create a SQL
Server data store in native
SQL Server format and you can create an
extended SQL Server Spatial data store with
FDO-enabled Data Stores
You specify whether the
new data store will be FDO-enabled or not by selecting Use
FDO Enabled Schema when you create a data store.
FDO-enabled data stores
include additional FDO metadata, but otherwise use native SQL Server
- Such metadata provides a mechanism for
ensuring that class and property names are maintained when you use Bulk
Copy to move the data to a different format and back
again. For SQL Server, the cases where class and property names
are not maintained are rare, since SQL Server can handle names with
any Unicode characters. The names cannot be longer than 128 characters,
which is not usually a problem.
- FDO data stores maintain class inheritance,
while non-FDO data stores do not. ApplySchema for non_FDO data stores
maintains the inherited properties for sub-classes but not the relationships
between classes and sub-classes.
- Object and object collection properties
are supported only with FDO metadata.
- Revision number support for optimistic
concurrency is included only with FDO metadata.
- If you select Use FDO Enabled Schema when
you create a data store, some columns or tables may be renamed in
the SQL Server database to avoid limitations in SQL Server. The
data itself is not altered and can still be queried by an external
application. You can later delete the metadata table.
is recommended that you use FDO-enabled schemas only if you need their
additional capabilities. Otherwise, choose the default, non-FDO-enabled schema.
Selecting a Coordinate
System for a Spatial Context
Once you create a data
store, you create and apply a schema to it. The schema defines the
table and columns into which you will put data. For FDO geometry
properties, there are two possible SQL Server Spatial column types: geometry
and geography. The geography type is used for geodetic (lat/long) coordinate
systems and the geometry type is used for non-geodetic coordinate
systems. For both, a spatial index with default parameters is created automatically.
SQL Server Spatial includes
a catalog of geodetic coordinate systems, but not non-geodetic coordinate
systems. Both geometry and geography column types save SRID values,
but only geography type columns reference an entry in the catalog,
and in this case the SRID numbers are EPSG numbers.
In AutoCAD Map 3D, when you
define a spatial context, you select a coordinate system from the
Mentor catalog. To use this coordinate system with SQL Server Spatial, AutoCAD Map 3D must
translate the coordinate system information from Mentor into an
SRID. SRID is the only identifier that SQL Server can use for both
geodetic and non-geodetic coordinate systems. AutoCAD Map 3D uses the
EPSG code of the coordinate system as the SRID.
The spatial context creation
can fail if either of the following is true:
- The coordinate system does not have an
- The coordinate system is in the SQL Server
catalog but its SQL Server WKT definition is not recognized by Mentor.
To resolve these situations,
use a translation table in the file ExtendedCoordSys.txt.
By default, this file is stored in FDO\bin\com in
the AutoCAD Map 3D installation folder.
If the coordinate system
does not have an EPSG code, add it to ExtendedCoordSys.txt and
specify an SRIDfor it. Choose an SRID number that is not an EPSG
code. The ExtendedCoordSys.txt file
contains instructions for doing this.
If the SQL Server WKT
definition is not recognized by mentor, add the coordinate system
to ExtendedCoordSys.txt (if
it is not already there) and set the WKT to the Mentor version.
The WKT specified in the file takes precedence over the WKT in the
SQL Server catalog.