|
|
|
Thomas Knoell-2
|
Some javascript/style in this post has been disabled (why?)
Hi, I
am working on a FDO based application that should use the King Oracle Provider
to connect to a data source on an Oracle 11g instance. The application
currently connects fine to an empty data store (the data store does not contain
any tables) and successfully applies a test schema that consists of a feature
and a non feature class. The problem arises in the following step where a
describe schema request is executed. In this case, the result is one schema
named KingOra and no classes. I expected the test schema and its
corresponding classes being reported. The
application has access to all the DLLs that come with FDO. The DLLs were
created by compiling the projects from the trunk in release mode. Due to the
fact that I use MS Visual Studio C++ 2008 Express Edition, I had to open each
solution and compile it separately as some of the projects referenced MFC files
that are not available with the Express Edition. Those issues were corrected in
the shadow and all builds succeeded. Besides
the changes to eliminate MFC references, one additional change was required in
the King Oracle provider project in that the references to Oracle 10 libs were
replaced by the corresponding Oracle 11 ones. Using
the command built.bat –c=release –a=install –o=c:\FdoHome
on the FDO and ThirdParty directory, all DLLs were copied into the specified
folder and hence made accessible to the FDO application. The
providers.xml file was modified to include the following statement for the King
Oracle Provider:
<FeatureProvider>
<Name>King.Oracle.3.5</Name>
<DisplayName>King Provider for Oracle</DisplayName>
<Description>Read/write access to spatial and attribute data
in an Oracle Spatial.</Description>
<IsManaged>False</IsManaged>
<Version>3.5.0.0</Version>
<FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion>
<LibraryPath>.\KingOracleProvider.dll</LibraryPath>
</FeatureProvider> I
did perform some debugging on the code. When following the statement that
retrieves the schema name (see code below), I noted that it does not hit the
function that implements the retrieval of the schema name but ends up in the
function FdoCollection::GetCount() (file FDO\Unmanaged\Inc\Common\Collection.h).
However, following other requests like the apply schema execute or the describe
schema execute call, the correct functions are hit and executed. I also did
some dependency checks on some DLLs and executables and nothing missing was
reported. I
assume that this may be just a simple setup issue but after trying multiple things
now, I reached a point where I am not sure what to try next. If someone has any
suggestions I would appreciate the feedback. Also, if there are additional
questions, please let me know. Thanks
Thomas
FdoPtr<FdoIDescribeSchema> describe_schema_cmd =
(FdoIDescribeSchema*) fdo_connection->CreateCommand(
FdoCommandType_DescribeSchema); FdoFeatureSchemasP
schema_collection = describe_schema_cmd->Execute(); FdoInt32 schema_count
= schema_collection->GetCount(); if (schema_count ==
0)
printf(" -> No schemas found \n"); else for (int
s = 0; s < schema_count; s++) {
FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s);
FdoStringP curr_schema_name = curr_schema->GetName();
printf(" -> Schema[%d]: %ls \n", s, (FdoString
*)curr_schema_name);
FdoPtr<FdoClassCollection> curr_schema_classes =
curr_schema->GetClasses();
FdoInt32 curr_schema_class_count = curr_schema_classes->GetCount();
if (curr_schema_class_count == 0)
printf(" -> No classes found for current schema
\n");
else
for (int sc = 0; sc < curr_schema_class_count; sc++) {
FdoPtr<FdoClassDefinition> curr_schema_class =
curr_schema_classes->GetItem(sc);
FdoStringP curr_schema_class_name = curr_schema_class->GetName();
printf(" -> Class[%d]: %ls \n",
sc,
(FdoString *)curr_schema_class_name);
} // for (int sc = 0; ... } // for (int s = 0; ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Greg Boone
|
Some javascript/style in this post has been disabled (why?)
For the debugging issue, look to
see if the pdb files that are loaded are the up to date for the dlls you are
using. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi, I
am working on a FDO based application that should use the King Oracle Provider
to connect to a data source on an Oracle 11g instance. The application
currently connects fine to an empty data store (the data store does not contain
any tables) and successfully applies a test schema that consists of a feature
and a non feature class. The problem arises in the following step where a
describe schema request is executed. In this case, the result is one schema
named KingOra and no classes. I expected the test schema and its
corresponding classes being reported. The
application has access to all the DLLs that come with FDO. The DLLs were
created by compiling the projects from the trunk in release mode. Due to the
fact that I use MS Visual Studio C++ 2008 Express Edition, I had to open each
solution and compile it separately as some of the projects referenced MFC files
that are not available with the Express Edition. Those issues were corrected in
the shadow and all builds succeeded. Besides
the changes to eliminate MFC references, one additional change was required in
the King Oracle provider project in that the references to Oracle 10 libs were
replaced by the corresponding Oracle 11 ones. Using
the command built.bat –c=release –a=install –o=c:\FdoHome
on the FDO and ThirdParty directory, all DLLs were copied into the specified
folder and hence made accessible to the FDO application. The
providers.xml file was modified to include the following statement for the King
Oracle Provider:
<FeatureProvider>
<Name>King.Oracle.3.5</Name>
<DisplayName>King Provider for Oracle</DisplayName>
<Description>Read/write access to spatial and attribute data
in an Oracle Spatial.</Description>
<IsManaged>False</IsManaged>
<Version>3.5.0.0</Version>
<FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion>
<LibraryPath>.\KingOracleProvider.dll</LibraryPath>
</FeatureProvider> I
did perform some debugging on the code. When following the statement that retrieves
the schema name (see code below), I noted that it does not hit the function
that implements the retrieval of the schema name but ends up in the function FdoCollection::GetCount()
(file FDO\Unmanaged\Inc\Common\Collection.h). However, following other
requests like the apply schema execute or the describe schema execute call, the
correct functions are hit and executed. I also did some dependency checks on
some DLLs and executables and nothing missing was reported. I
assume that this may be just a simple setup issue but after trying multiple
things now, I reached a point where I am not sure what to try next. If someone
has any suggestions I would appreciate the feedback. Also, if there are
additional questions, please let me know. Thanks
Thomas
FdoPtr<FdoIDescribeSchema> describe_schema_cmd =
(FdoIDescribeSchema*) fdo_connection->CreateCommand(
FdoCommandType_DescribeSchema);
FdoFeatureSchemasP schema_collection = describe_schema_cmd->Execute();
FdoInt32 schema_count = schema_collection->GetCount();
if (schema_count == 0)
printf(" -> No schemas found \n");
else
for (int s = 0; s < schema_count; s++) {
FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s);
FdoStringP curr_schema_name = curr_schema->GetName();
printf(" -> Schema[%d]: %ls \n", s, (FdoString
*)curr_schema_name);
FdoPtr<FdoClassCollection> curr_schema_classes =
curr_schema->GetClasses();
FdoInt32 curr_schema_class_count = curr_schema_classes->GetCount();
if (curr_schema_class_count == 0)
printf(" -> No classes found for current schema
\n");
else
for (int sc = 0; sc < curr_schema_class_count; sc++) {
FdoPtr<FdoClassDefinition> curr_schema_class =
curr_schema_classes->GetItem(sc);
FdoStringP curr_schema_class_name = curr_schema_class->GetName();
printf(" -> Class[%d]: %ls \n",
sc,
(FdoString *)curr_schema_class_name);
} // for (int sc = 0; ...
} // for (int s = 0; ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
|
Thomas Knoell-2
|
Some javascript/style in this post has been disabled (why?)
Build.bat copies the DLL and PDB files from the source to the
target location. So I assume that those are in sync after the build is
executed. But I check. From: [hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone For the debugging
issue, look to see if the pdb files that are loaded are the up to date for the
dlls you are using. From: [hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi, I
am working on a FDO based application that should use the King Oracle Provider
to connect to a data source on an Oracle 11g instance. The application
currently connects fine to an empty data store (the data store does not contain
any tables) and successfully applies a test schema that consists of a feature
and a non feature class. The problem arises in the following step where a
describe schema request is executed. In this case, the result is one schema
named KingOra and no classes. I expected the test schema and its
corresponding classes being reported. The
application has access to all the DLLs that come with FDO. The DLLs were
created by compiling the projects from the trunk in release mode. Due to the
fact that I use MS Visual Studio C++ 2008 Express Edition, I had to open each
solution and compile it separately as some of the projects referenced MFC files
that are not available with the Express Edition. Those issues were corrected in
the shadow and all builds succeeded. Besides
the changes to eliminate MFC references, one additional change was required in
the King Oracle provider project in that the references to Oracle 10 libs were
replaced by the corresponding Oracle 11 ones. Using
the command built.bat –c=release –a=install –o=c:\FdoHome
on the FDO and ThirdParty directory, all DLLs were copied into the specified
folder and hence made accessible to the FDO application. The
providers.xml file was modified to include the following statement for the King
Oracle Provider:
<FeatureProvider>
<Name>King.Oracle.3.5</Name>
<DisplayName>King Provider for Oracle</DisplayName>
<Description>Read/write access to spatial and attribute data
in an Oracle Spatial.</Description>
<IsManaged>False</IsManaged>
<Version>3.5.0.0</Version>
<FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion>
<LibraryPath>.\KingOracleProvider.dll</LibraryPath>
</FeatureProvider> I
did perform some debugging on the code. When following the statement that
retrieves the schema name (see code below), I noted that it does not hit the
function that implements the retrieval of the schema name but ends up in the
function FdoCollection::GetCount() (file FDO\Unmanaged\Inc\Common\Collection.h).
However, following other requests like the apply schema execute or the describe
schema execute call, the correct functions are hit and executed. I also did some
dependency checks on some DLLs and executables and nothing missing was
reported. I
assume that this may be just a simple setup issue but after trying multiple
things now, I reached a point where I am not sure what to try next. If someone
has any suggestions I would appreciate the feedback. Also, if there are
additional questions, please let me know. Thanks
Thomas
FdoPtr<FdoIDescribeSchema> describe_schema_cmd =
(FdoIDescribeSchema*) fdo_connection->CreateCommand(
FdoCommandType_DescribeSchema); FdoFeatureSchemasP
schema_collection = describe_schema_cmd->Execute(); FdoInt32 schema_count
= schema_collection->GetCount(); if (schema_count ==
0)
printf(" -> No schemas found \n"); else for (int
s = 0; s < schema_count; s++) {
FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s);
FdoStringP curr_schema_name = curr_schema->GetName();
printf(" -> Schema[%d]: %ls \n", s, (FdoString
*)curr_schema_name);
FdoPtr<FdoClassCollection> curr_schema_classes =
curr_schema->GetClasses();
FdoInt32 curr_schema_class_count = curr_schema_classes->GetCount();
if (curr_schema_class_count == 0)
printf(" -> No classes found for current schema
\n");
else
for (int sc = 0; sc < curr_schema_class_count; sc++) {
FdoPtr<FdoClassDefinition> curr_schema_class =
curr_schema_classes->GetItem(sc);
FdoStringP curr_schema_class_name = curr_schema_class->GetName();
printf(" -> Class[%d]: %ls \n",
sc,
(FdoString *)curr_schema_class_name);
} // for (int sc = 0; ... } // for (int s = 0; ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Haris Kurtagic
|
In reply to this post
by Thomas Knoell-2
Some javascript/style in this post has been disabled (why?)
How did you applied schema ? You
mention feature and non-feature class ? You applied Autodesk schema , metadata
tables? In King.Oracle for Oracle Table
to become available as FDO class the table has to be in sdo_geom_metadata . You
did that ? Of 'course Oracle user you are
using to connect has to see those tables etc... Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi, I
am working on a FDO based application that should use the King Oracle Provider
to connect to a data source on an Oracle 11g instance. The application
currently connects fine to an empty data store (the data store does not contain
any tables) and successfully applies a test schema that consists of a feature
and a non feature class. The problem arises in the following step where a
describe schema request is executed. In this case, the result is one schema
named KingOra and no classes. I expected the test schema and its
corresponding classes being reported. The
application has access to all the DLLs that come with FDO. The DLLs were created
by compiling the projects from the trunk in release mode. Due to the fact that
I use MS Visual Studio C++ 2008 Express Edition, I had to open each solution
and compile it separately as some of the projects referenced MFC files that are
not available with the Express Edition. Those issues were corrected in the
shadow and all builds succeeded. Besides
the changes to eliminate MFC references, one additional change was required in
the King Oracle provider project in that the references to Oracle 10 libs were
replaced by the corresponding Oracle 11 ones. Using
the command built.bat –c=release –a=install –o=c:\FdoHome on the FDO and
ThirdParty directory, all DLLs were copied into the specified folder and hence
made accessible to the FDO application. The
providers.xml file was modified to include the following statement for the King
Oracle Provider:
<FeatureProvider>
<Name>King.Oracle.3.5</Name>
<DisplayName>King Provider for Oracle</DisplayName>
<Description>Read/write access to spatial and attribute data
in an Oracle Spatial.</Description>
<IsManaged>False</IsManaged>
<Version>3.5.0.0</Version>
<FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion>
<LibraryPath>.\KingOracleProvider.dll</LibraryPath>
</FeatureProvider> I
did perform some debugging on the code. When following the statement that
retrieves the schema name (see code below), I noted that it does not hit the
function that implements the retrieval of the schema name but ends up in the
function FdoCollection::GetCount() (file FDO\Unmanaged\Inc\Common\Collection.h).
However, following other requests like the apply schema execute or the describe
schema execute call, the correct functions are hit and executed. I also did
some dependency checks on some DLLs and executables and nothing missing was
reported. I
assume that this may be just a simple setup issue but after trying multiple
things now, I reached a point where I am not sure what to try next. If someone
has any suggestions I would appreciate the feedback. Also, if there are
additional questions, please let me know. Thanks
Thomas
FdoPtr<FdoIDescribeSchema> describe_schema_cmd =
(FdoIDescribeSchema*) fdo_connection->CreateCommand(
FdoCommandType_DescribeSchema);
FdoFeatureSchemasP schema_collection = describe_schema_cmd->Execute();
FdoInt32 schema_count = schema_collection->GetCount();
if (schema_count == 0)
printf(" -> No schemas found \n");
else
for (int s = 0; s < schema_count; s++) {
FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s);
FdoStringP curr_schema_name = curr_schema->GetName();
printf(" -> Schema[%d]: %ls \n", s, (FdoString *)curr_schema_name);
FdoPtr<FdoClassCollection> curr_schema_classes =
curr_schema->GetClasses();
FdoInt32 curr_schema_class_count = curr_schema_classes->GetCount();
if (curr_schema_class_count == 0)
printf(" -> No classes found for current schema
\n");
else
for (int sc = 0; sc < curr_schema_class_count; sc++) {
FdoPtr<FdoClassDefinition> curr_schema_class =
curr_schema_classes->GetItem(sc);
FdoStringP curr_schema_class_name = curr_schema_class->GetName();
printf(" -> Class[%d]: %ls \n",
sc,
(FdoString *)curr_schema_class_name);
} // for (int sc = 0; ...
} // for (int s = 0; ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Thomas Knoell-2
|
Some javascript/style in this post has been disabled (why?)
Hi Haris, Here are the answers to your questions: >> How did
you applied schema ? You mention feature and non-feature class ? I executed the apply schema command (see below) from the FDO
application. The schema that is defined and then applied contains a
FdoFeatureClass and FdoClass. The application has to work with data stores that
contain tables with and without spatial information and must be able to
maintain them. That is why the test schema contains both classes. >> You
applied Autodesk schema , metadata tables? The original data store did not contain any tables. However,
since you mentioned it here, I added the f_* tables and tried it again –
same result. >> In
King.Oracle for Oracle Table to become available as FDO class the table has to
be in sdo_geom_metadata . You did that ? >> Of 'course Oracle
user you are using to connect has to see those tables etc... Since the schema was applied with the FdoIApplySchema interface,
this should have been taken care of automatically. I checked and the feature
class table does show up in sdo_geom_metadata. Obviously, the non feature class
does not. And the Oracle user the application is connecting to can see those
tables. So, are you saying that if I connect to an Oracle data store that does have
tables without spatial information, I would not be able to use the insert/delete/update
commands to maintain them when working with the King Oracle provider? Thanks Thomas
FdoPtr<FdoIApplySchema> apply_schema_cmd =
(FdoIApplySchema*) fdo_connection->CreateCommand(
FdoCommandType_ApplySchema);
FdoPtr<FdoFeatureSchemaCollection> schemas =
FdoFeatureSchemaCollection::Create(NULL);
FdoPtr<FdoFeatureSchema> schema =
FdoFeatureSchema::Create(L"TestSchema", L"Test Schema");
FdoPtr<FdoClassCollection> classes = schema->GetClasses();
printf(" -> Defining feature class fc \n");
FdoPtr<FdoFeatureClass> fc_class =
FdoFeatureClass::Create(L"fc", L"fc");
fc_class->SetIsAbstract(false); FdoPropertyDefinitionCollection
*data_property_definitions =
fc_class->GetProperties();
FdoDataPropertyDefinitionCollection *id_property_definitions =
fc_class->GetIdentityProperties();
FdoDataPropertyDefinition *data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
data_property_definition->SetDataType(FdoDataType_Int64);
data_property_definition->SetNullable(false);
data_property_definition->SetIsAutoGenerated(true);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
FdoGeometricPropertyDefinition *geometric_property_definition =
FdoGeometricPropertyDefinition::Create(L"GProp",L"GProp");
geometric_property_definition->SetGeometryTypes(
FdoGeometricType_Point |
FdoGeometricType_Curve |
FdoGeometricType_Surface |
FdoGeometricType_Solid );
geometric_property_definition->SetHasElevation(true);
data_property_definitions->Add(geometric_property_definition);
fc_class->SetGeometryProperty(geometric_property_definition);
FDO_SAFE_RELEASE(geometric_property_definition);
FDO_SAFE_RELEASE(id_property_definitions); FDO_SAFE_RELEASE(data_property_definitions);
fc_class->SetBaseClass(NULL);
classes->Add(fc_class);
printf(" -> Defining non feature class nfc \n");
FdoPtr<FdoClass> nfc_class = FdoClass::Create(L"nfc",
L"nfc");
nfc_class->SetIsAbstract(false);
data_property_definitions = nfc_class->GetProperties();
id_property_definitions = nfc_class->GetIdentityProperties();
data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp"); data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(false);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
FDO_SAFE_RELEASE(id_property_definitions);
FDO_SAFE_RELEASE(data_property_definitions);
nfc_class->SetBaseClass(NULL);
classes->Add(nfc_class);
schemas->Add(schema);
printf(" -> Applying the schema \n");
apply_schema_cmd->SetFeatureSchema(schema);
apply_schema_cmd->Execute(); From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic How did you applied
schema ? You mention feature and non-feature class ? You applied Autodesk
schema , metadata tables? In King.Oracle for
Oracle Table to become available as FDO class the table has to be in
sdo_geom_metadata . You did that ? Of 'course Oracle
user you are using to connect has to see those tables etc... Haris From: [hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi, I
am working on a FDO based application that should use the King Oracle Provider
to connect to a data source on an Oracle 11g instance. The application
currently connects fine to an empty data store (the data store does not contain
any tables) and successfully applies a test schema that consists of a feature
and a non feature class. The problem arises in the following step where a
describe schema request is executed. In this case, the result is one schema
named KingOra and no classes. I expected the test schema and its
corresponding classes being reported. The
application has access to all the DLLs that come with FDO. The DLLs were
created by compiling the projects from the trunk in release mode. Due to the
fact that I use MS Visual Studio C++ 2008 Express Edition, I had to open each
solution and compile it separately as some of the projects referenced MFC files
that are not available with the Express Edition. Those issues were corrected in
the shadow and all builds succeeded. Besides
the changes to eliminate MFC references, one additional change was required in
the King Oracle provider project in that the references to Oracle 10 libs were
replaced by the corresponding Oracle 11 ones. Using
the command built.bat –c=release –a=install –o=c:\FdoHome
on the FDO and ThirdParty directory, all DLLs were copied into the specified
folder and hence made accessible to the FDO application. The
providers.xml file was modified to include the following statement for the King
Oracle Provider:
<FeatureProvider>
<Name>King.Oracle.3.5</Name>
<DisplayName>King Provider for Oracle</DisplayName>
<Description>Read/write access to spatial and attribute data
in an Oracle Spatial.</Description>
<IsManaged>False</IsManaged>
<Version>3.5.0.0</Version>
<FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion>
<LibraryPath>.\KingOracleProvider.dll</LibraryPath>
</FeatureProvider> I
did perform some debugging on the code. When following the statement that
retrieves the schema name (see code below), I noted that it does not hit the
function that implements the retrieval of the schema name but ends up in the
function FdoCollection::GetCount() (file FDO\Unmanaged\Inc\Common\Collection.h).
However, following other requests like the apply schema execute or the describe
schema execute call, the correct functions are hit and executed. I also did
some dependency checks on some DLLs and executables and nothing missing was reported. I
assume that this may be just a simple setup issue but after trying multiple
things now, I reached a point where I am not sure what to try next. If someone
has any suggestions I would appreciate the feedback. Also, if there are
additional questions, please let me know. Thanks
Thomas
FdoPtr<FdoIDescribeSchema> describe_schema_cmd =
(FdoIDescribeSchema*) fdo_connection->CreateCommand(
FdoCommandType_DescribeSchema); FdoFeatureSchemasP
schema_collection = describe_schema_cmd->Execute(); FdoInt32 schema_count
= schema_collection->GetCount(); if (schema_count ==
0)
printf(" -> No schemas found \n"); else for (int
s = 0; s < schema_count; s++) {
FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s);
FdoStringP curr_schema_name = curr_schema->GetName();
printf(" -> Schema[%d]: %ls \n", s, (FdoString
*)curr_schema_name);
FdoPtr<FdoClassCollection> curr_schema_classes =
curr_schema->GetClasses();
FdoInt32 curr_schema_class_count = curr_schema_classes->GetCount();
if (curr_schema_class_count == 0)
printf(" -> No classes found for current schema
\n");
else
for (int sc = 0; sc < curr_schema_class_count; sc++) {
FdoPtr<FdoClassDefinition> curr_schema_class =
curr_schema_classes->GetItem(sc);
FdoStringP curr_schema_class_name = curr_schema_class->GetName();
printf(" -> Class[%d]: %ls \n",
sc,
(FdoString *)curr_schema_class_name);
} // for (int sc = 0; ... } // for (int s = 0; ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Haris Kurtagic
|
Some javascript/style in this post has been disabled (why?)
For tables which are not in sdo_geom_metadata
you need to add them using "KingFdoClass" table (http://www.sl-king.com/fdooracle/KingFdoClass.htm). One reason I can remember right
now for not working, would be because FDO schema is cached. You would need to
restart provider ( there is also non-standard FDO function in King.Oracle
connection). Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi Haris, Here are the answers to your questions: >> How did you applied
schema ? You mention feature and non-feature class ? I executed the apply schema command (see below) from the FDO
application. The schema that is defined and then applied contains a
FdoFeatureClass and FdoClass. The application has to work with data stores that
contain tables with and without spatial information and must be able to
maintain them. That is why the test schema contains both classes. >> You applied Autodesk
schema , metadata tables? The original data store did not contain any tables. However,
since you mentioned it here, I added the f_* tables and tried it again –
same result. >> In King.Oracle for
Oracle Table to become available as FDO class the table has to be in
sdo_geom_metadata . You did that ? >> Of 'course Oracle user
you are using to connect has to see those tables etc... Since the schema was applied with the FdoIApplySchema interface,
this should have been taken care of automatically. I checked and the feature class
table does show up in sdo_geom_metadata. Obviously, the non feature class does
not. And the Oracle user the application is connecting to can see those tables.
So, are you saying that if I connect to an Oracle data store that does have
tables without spatial information, I would not be able to use the
insert/delete/update commands to maintain them when working with the King
Oracle provider? Thanks Thomas
FdoPtr<FdoIApplySchema> apply_schema_cmd =
(FdoIApplySchema*) fdo_connection->CreateCommand(
FdoCommandType_ApplySchema);
FdoPtr<FdoFeatureSchemaCollection> schemas =
FdoFeatureSchemaCollection::Create(NULL);
FdoPtr<FdoFeatureSchema> schema =
FdoFeatureSchema::Create(L"TestSchema", L"Test Schema");
FdoPtr<FdoClassCollection> classes = schema->GetClasses();
printf(" -> Defining feature class fc \n");
FdoPtr<FdoFeatureClass> fc_class = FdoFeatureClass::Create(L"fc",
L"fc");
fc_class->SetIsAbstract(false);
FdoPropertyDefinitionCollection *data_property_definitions =
fc_class->GetProperties();
FdoDataPropertyDefinitionCollection *id_property_definitions =
fc_class->GetIdentityProperties();
FdoDataPropertyDefinition *data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
data_property_definition->SetDataType(FdoDataType_Int64);
data_property_definition->SetNullable(false);
data_property_definition->SetIsAutoGenerated(true);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
FdoGeometricPropertyDefinition *geometric_property_definition =
FdoGeometricPropertyDefinition::Create(L"GProp",L"GProp");
geometric_property_definition->SetGeometryTypes(
FdoGeometricType_Point |
FdoGeometricType_Curve |
FdoGeometricType_Surface |
FdoGeometricType_Solid );
geometric_property_definition->SetHasElevation(true);
data_property_definitions->Add(geometric_property_definition);
fc_class->SetGeometryProperty(geometric_property_definition);
FDO_SAFE_RELEASE(geometric_property_definition);
FDO_SAFE_RELEASE(id_property_definitions);
FDO_SAFE_RELEASE(data_property_definitions);
fc_class->SetBaseClass(NULL);
classes->Add(fc_class);
printf(" -> Defining non feature class nfc \n");
FdoPtr<FdoClass> nfc_class = FdoClass::Create(L"nfc",
L"nfc");
nfc_class->SetIsAbstract(false);
data_property_definitions = nfc_class->GetProperties();
id_property_definitions = nfc_class->GetIdentityProperties();
data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(false);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
FDO_SAFE_RELEASE(id_property_definitions);
FDO_SAFE_RELEASE(data_property_definitions);
nfc_class->SetBaseClass(NULL);
classes->Add(nfc_class);
schemas->Add(schema);
printf(" -> Applying the schema \n");
apply_schema_cmd->SetFeatureSchema(schema);
apply_schema_cmd->Execute(); From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic How did you applied schema ? You
mention feature and non-feature class ? You applied Autodesk schema , metadata
tables? In King.Oracle for Oracle Table
to become available as FDO class the table has to be in sdo_geom_metadata . You
did that ? Of 'course Oracle user you are
using to connect has to see those tables etc... Haris From:
[hidden email] [mailto:[hidden email]]
On Behalf Of Thomas Knoell Hi, I
am working on a FDO based application that should use the King Oracle Provider
to connect to a data source on an Oracle 11g instance. The application
currently connects fine to an empty data store (the data store does not contain
any tables) and successfully applies a test schema that consists of a feature
and a non feature class. The problem arises in the following step where a
describe schema request is executed. In this case, the result is one schema
named KingOra and no classes. I expected the test schema and its
corresponding classes being reported. The
application has access to all the DLLs that come with FDO. The DLLs were
created by compiling the projects from the trunk in release mode. Due to the
fact that I use MS Visual Studio C++ 2008 Express Edition, I had to open each
solution and compile it separately as some of the projects referenced MFC files
that are not available with the Express Edition. Those issues were corrected in
the shadow and all builds succeeded. Besides
the changes to eliminate MFC references, one additional change was required in
the King Oracle provider project in that the references to Oracle 10 libs were
replaced by the corresponding Oracle 11 ones. Using
the command built.bat –c=release –a=install –o=c:\FdoHome
on the FDO and ThirdParty directory, all DLLs were copied into the specified
folder and hence made accessible to the FDO application. The
providers.xml file was modified to include the following statement for the King
Oracle Provider:
<FeatureProvider>
<Name>King.Oracle.3.5</Name>
<DisplayName>King Provider for Oracle</DisplayName>
<Description>Read/write access to spatial and attribute data
in an Oracle Spatial.</Description>
<IsManaged>False</IsManaged>
<Version>3.5.0.0</Version>
<FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion>
<LibraryPath>.\KingOracleProvider.dll</LibraryPath>
</FeatureProvider> I
did perform some debugging on the code. When following the statement that
retrieves the schema name (see code below), I noted that it does not hit the
function that implements the retrieval of the schema name but ends up in the
function FdoCollection::GetCount() (file FDO\Unmanaged\Inc\Common\Collection.h).
However, following other requests like the apply schema execute or the describe
schema execute call, the correct functions are hit and executed. I also did
some dependency checks on some DLLs and executables and nothing missing was
reported. I
assume that this may be just a simple setup issue but after trying multiple
things now, I reached a point where I am not sure what to try next. If someone
has any suggestions I would appreciate the feedback. Also, if there are
additional questions, please let me know. Thanks
Thomas
FdoPtr<FdoIDescribeSchema> describe_schema_cmd =
(FdoIDescribeSchema*) fdo_connection->CreateCommand(
FdoCommandType_DescribeSchema);
FdoFeatureSchemasP schema_collection = describe_schema_cmd->Execute();
FdoInt32 schema_count = schema_collection->GetCount();
if (schema_count == 0)
printf(" -> No schemas found \n");
else
for (int s = 0; s < schema_count; s++) {
FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s);
FdoStringP curr_schema_name = curr_schema->GetName();
printf(" -> Schema[%d]: %ls \n", s, (FdoString
*)curr_schema_name);
FdoPtr<FdoClassCollection> curr_schema_classes =
curr_schema->GetClasses();
FdoInt32 curr_schema_class_count = curr_schema_classes->GetCount();
if (curr_schema_class_count == 0)
printf(" -> No classes found for current schema
\n");
else
for (int sc = 0; sc < curr_schema_class_count; sc++) {
FdoPtr<FdoClassDefinition> curr_schema_class =
curr_schema_classes->GetItem(sc);
FdoStringP curr_schema_class_name = curr_schema_class->GetName();
printf(" -> Class[%d]: %ls \n",
sc,
(FdoString *)curr_schema_class_name);
} // for (int sc = 0; ...
} // for (int s = 0; ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Haris Kurtagic
|
Some javascript/style in this post has been disabled (why?)
That is not correct what I wrote.
Execution of Apply schema would clear cached schema. Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic For tables which are not in
sdo_geom_metadata you need to add them using "KingFdoClass" table (http://www.sl-king.com/fdooracle/KingFdoClass.htm). One reason I can remember right now
for not working, would be because FDO schema is cached. You would need to
restart provider ( there is also non-standard FDO function in King.Oracle
connection). Haris From:
[hidden email] [mailto:[hidden email]]
On Behalf Of Thomas Knoell Hi Haris, Here are the answers to your questions: >> How did you applied
schema ? You mention feature and non-feature class ? I executed the apply schema command (see below) from the FDO
application. The schema that is defined and then applied contains a
FdoFeatureClass and FdoClass. The application has to work with data stores that
contain tables with and without spatial information and must be able to
maintain them. That is why the test schema contains both classes. >> You applied Autodesk
schema , metadata tables? The original data store did not contain any tables. However,
since you mentioned it here, I added the f_* tables and tried it again – same
result. >> In King.Oracle for
Oracle Table to become available as FDO class the table has to be in
sdo_geom_metadata . You did that ? >> Of 'course Oracle user
you are using to connect has to see those tables etc... Since the schema was applied with the FdoIApplySchema interface,
this should have been taken care of automatically. I checked and the feature
class table does show up in sdo_geom_metadata. Obviously, the non feature class
does not. And the Oracle user the application is connecting to can see those
tables. So, are you saying that if I connect to an Oracle data store that does
have tables without spatial information, I would not be able to use the
insert/delete/update commands to maintain them when working with the King
Oracle provider? Thanks Thomas
FdoPtr<FdoIApplySchema> apply_schema_cmd =
(FdoIApplySchema*) fdo_connection->CreateCommand(
FdoCommandType_ApplySchema);
FdoPtr<FdoFeatureSchemaCollection> schemas =
FdoFeatureSchemaCollection::Create(NULL);
FdoPtr<FdoFeatureSchema> schema =
FdoFeatureSchema::Create(L"TestSchema", L"Test Schema");
FdoPtr<FdoClassCollection> classes = schema->GetClasses();
printf(" -> Defining feature class fc \n");
FdoPtr<FdoFeatureClass> fc_class =
FdoFeatureClass::Create(L"fc", L"fc");
fc_class->SetIsAbstract(false);
FdoPropertyDefinitionCollection *data_property_definitions =
fc_class->GetProperties();
FdoDataPropertyDefinitionCollection *id_property_definitions =
fc_class->GetIdentityProperties();
FdoDataPropertyDefinition *data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
data_property_definition->SetDataType(FdoDataType_Int64);
data_property_definition->SetNullable(false);
data_property_definition->SetIsAutoGenerated(true);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
FdoGeometricPropertyDefinition *geometric_property_definition =
FdoGeometricPropertyDefinition::Create(L"GProp",L"GProp");
geometric_property_definition->SetGeometryTypes(
FdoGeometricType_Point |
FdoGeometricType_Curve |
FdoGeometricType_Surface |
FdoGeometricType_Solid );
geometric_property_definition->SetHasElevation(true);
data_property_definitions->Add(geometric_property_definition);
fc_class->SetGeometryProperty(geometric_property_definition);
FDO_SAFE_RELEASE(geometric_property_definition);
FDO_SAFE_RELEASE(id_property_definitions);
FDO_SAFE_RELEASE(data_property_definitions);
fc_class->SetBaseClass(NULL);
classes->Add(fc_class);
printf(" -> Defining non feature class nfc \n");
FdoPtr<FdoClass> nfc_class = FdoClass::Create(L"nfc",
L"nfc");
nfc_class->SetIsAbstract(false);
data_property_definitions = nfc_class->GetProperties();
id_property_definitions = nfc_class->GetIdentityProperties();
data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(false);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
FDO_SAFE_RELEASE(id_property_definitions);
FDO_SAFE_RELEASE(data_property_definitions);
nfc_class->SetBaseClass(NULL);
classes->Add(nfc_class);
schemas->Add(schema);
printf(" -> Applying the schema \n");
apply_schema_cmd->SetFeatureSchema(schema);
apply_schema_cmd->Execute(); From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic How did you applied schema ? You
mention feature and non-feature class ? You applied Autodesk schema , metadata
tables? In King.Oracle for Oracle Table
to become available as FDO class the table has to be in sdo_geom_metadata . You
did that ? Of 'course Oracle user you are
using to connect has to see those tables etc... Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi, I
am working on a FDO based application that should use the King Oracle Provider
to connect to a data source on an Oracle 11g instance. The application
currently connects fine to an empty data store (the data store does not contain
any tables) and successfully applies a test schema that consists of a feature
and a non feature class. The problem arises in the following step where a
describe schema request is executed. In this case, the result is one schema
named KingOra and no classes. I expected the test schema and its
corresponding classes being reported. The
application has access to all the DLLs that come with FDO. The DLLs were created
by compiling the projects from the trunk in release mode. Due to the fact that
I use MS Visual Studio C++ 2008 Express Edition, I had to open each solution
and compile it separately as some of the projects referenced MFC files that are
not available with the Express Edition. Those issues were corrected in the
shadow and all builds succeeded. Besides
the changes to eliminate MFC references, one additional change was required in
the King Oracle provider project in that the references to Oracle 10 libs were
replaced by the corresponding Oracle 11 ones. Using
the command built.bat –c=release –a=install –o=c:\FdoHome on the FDO and
ThirdParty directory, all DLLs were copied into the specified folder and hence
made accessible to the FDO application. The
providers.xml file was modified to include the following statement for the King
Oracle Provider:
<FeatureProvider>
<Name>King.Oracle.3.5</Name>
<DisplayName>King Provider for Oracle</DisplayName>
<Description>Read/write access to spatial and attribute data
in an Oracle Spatial.</Description>
<IsManaged>False</IsManaged>
<Version>3.5.0.0</Version>
<FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion>
<LibraryPath>.\KingOracleProvider.dll</LibraryPath>
</FeatureProvider> I
did perform some debugging on the code. When following the statement that
retrieves the schema name (see code below), I noted that it does not hit the
function that implements the retrieval of the schema name but ends up in the
function FdoCollection::GetCount() (file FDO\Unmanaged\Inc\Common\Collection.h).
However, following other requests like the apply schema execute or the describe
schema execute call, the correct functions are hit and executed. I also did some
dependency checks on some DLLs and executables and nothing missing was
reported. I
assume that this may be just a simple setup issue but after trying multiple
things now, I reached a point where I am not sure what to try next. If someone
has any suggestions I would appreciate the feedback. Also, if there are
additional questions, please let me know. Thanks
Thomas
FdoPtr<FdoIDescribeSchema> describe_schema_cmd =
(FdoIDescribeSchema*) fdo_connection->CreateCommand(
FdoCommandType_DescribeSchema);
FdoFeatureSchemasP schema_collection = describe_schema_cmd->Execute();
FdoInt32 schema_count = schema_collection->GetCount();
if (schema_count == 0)
printf(" -> No schemas found \n");
else
for (int s = 0; s < schema_count; s++) {
FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s);
FdoStringP curr_schema_name = curr_schema->GetName();
printf(" -> Schema[%d]: %ls \n", s, (FdoString
*)curr_schema_name);
FdoPtr<FdoClassCollection> curr_schema_classes =
curr_schema->GetClasses();
FdoInt32 curr_schema_class_count = curr_schema_classes->GetCount();
if (curr_schema_class_count == 0)
printf(" -> No classes found for current schema
\n");
else
for (int sc = 0; sc < curr_schema_class_count; sc++) {
FdoPtr<FdoClassDefinition> curr_schema_class =
curr_schema_classes->GetItem(sc);
FdoStringP curr_schema_class_name = curr_schema_class->GetName();
printf(" -> Class[%d]: %ls \n",
sc,
(FdoString *)curr_schema_class_name);
} // for (int sc = 0; ...
} // for (int s = 0; ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Thomas Knoell-2
|
In reply to this post
by Haris Kurtagic
Some javascript/style in this post has been disabled (why?)
Hi Haris, Thanks for the provided link, that is helpful. I created the table, added the information to the connection
string and executed the test. I noted that the ApplySchema command is not
adding any specified non feature classes to that table. Since the link you
provided indicates that this is in Beta release at this point, is your final
version enhancing your ApplySchema command implementation to automatically update
this table for non feature classes? Thanks Thomas From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic For tables which are
not in sdo_geom_metadata you need to add them using "KingFdoClass"
table (http://www.sl-king.com/fdooracle/KingFdoClass.htm). One reason I can
remember right now for not working, would be because FDO schema is cached. You
would need to restart provider ( there is also non-standard FDO function in
King.Oracle connection). Haris From: [hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi Haris, Here are the answers to your questions: >> How did
you applied schema ? You mention feature and non-feature class ? I executed the apply schema command (see below) from the FDO
application. The schema that is defined and then applied contains a FdoFeatureClass
and FdoClass. The application has to work with data stores that contain tables
with and without spatial information and must be able to maintain them. That is
why the test schema contains both classes. >> You
applied Autodesk schema , metadata tables? The original data store did not contain any tables. However,
since you mentioned it here, I added the f_* tables and tried it again –
same result. >> In
King.Oracle for Oracle Table to become available as FDO class the table has to
be in sdo_geom_metadata . You did that ? >> Of 'course
Oracle user you are using to connect has to see those tables etc... Since the schema was applied with the FdoIApplySchema interface,
this should have been taken care of automatically. I checked and the feature
class table does show up in sdo_geom_metadata. Obviously, the non feature class
does not. And the Oracle user the application is connecting to can see those
tables. So, are you saying that if I connect to an Oracle data store that does
have tables without spatial information, I would not be able to use the
insert/delete/update commands to maintain them when working with the King
Oracle provider? Thanks Thomas
FdoPtr<FdoIApplySchema> apply_schema_cmd = (FdoIApplySchema*)
fdo_connection->CreateCommand(
FdoCommandType_ApplySchema);
FdoPtr<FdoFeatureSchemaCollection> schemas =
FdoFeatureSchemaCollection::Create(NULL);
FdoPtr<FdoFeatureSchema> schema =
FdoFeatureSchema::Create(L"TestSchema", L"Test Schema");
FdoPtr<FdoClassCollection> classes = schema->GetClasses();
printf(" -> Defining feature class fc \n");
FdoPtr<FdoFeatureClass> fc_class =
FdoFeatureClass::Create(L"fc", L"fc");
fc_class->SetIsAbstract(false);
FdoPropertyDefinitionCollection *data_property_definitions =
fc_class->GetProperties();
FdoDataPropertyDefinitionCollection *id_property_definitions =
fc_class->GetIdentityProperties();
FdoDataPropertyDefinition *data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
data_property_definition->SetDataType(FdoDataType_Int64);
data_property_definition->SetNullable(false);
data_property_definition->SetIsAutoGenerated(true);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition); FDO_SAFE_RELEASE(data_property_definition);
FdoGeometricPropertyDefinition *geometric_property_definition =
FdoGeometricPropertyDefinition::Create(L"GProp",L"GProp");
geometric_property_definition->SetGeometryTypes(
FdoGeometricType_Point |
FdoGeometricType_Curve |
FdoGeometricType_Surface |
FdoGeometricType_Solid );
geometric_property_definition->SetHasElevation(true);
data_property_definitions->Add(geometric_property_definition);
fc_class->SetGeometryProperty(geometric_property_definition);
FDO_SAFE_RELEASE(geometric_property_definition);
FDO_SAFE_RELEASE(id_property_definitions);
FDO_SAFE_RELEASE(data_property_definitions);
fc_class->SetBaseClass(NULL);
classes->Add(fc_class);
printf(" -> Defining non feature class nfc \n");
FdoPtr<FdoClass> nfc_class = FdoClass::Create(L"nfc",
L"nfc");
nfc_class->SetIsAbstract(false);
data_property_definitions = nfc_class->GetProperties();
id_property_definitions = nfc_class->GetIdentityProperties();
data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(false); data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false); data_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
FDO_SAFE_RELEASE(id_property_definitions);
FDO_SAFE_RELEASE(data_property_definitions);
nfc_class->SetBaseClass(NULL); classes->Add(nfc_class);
schemas->Add(schema);
printf(" -> Applying the schema \n");
apply_schema_cmd->SetFeatureSchema(schema);
apply_schema_cmd->Execute(); From: [hidden email] [mailto:[hidden email]]
On Behalf Of Haris Kurtagic How did you applied
schema ? You mention feature and non-feature class ? You applied Autodesk
schema , metadata tables? In King.Oracle for
Oracle Table to become available as FDO class the table has to be in
sdo_geom_metadata . You did that ? Of 'course Oracle
user you are using to connect has to see those tables etc... Haris From: [hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi, I
am working on a FDO based application that should use the King Oracle Provider
to connect to a data source on an Oracle 11g instance. The application
currently connects fine to an empty data store (the data store does not contain
any tables) and successfully applies a test schema that consists of a feature
and a non feature class. The problem arises in the following step where a
describe schema request is executed. In this case, the result is one schema
named KingOra and no classes. I expected the test schema and its
corresponding classes being reported. The
application has access to all the DLLs that come with FDO. The DLLs were
created by compiling the projects from the trunk in release mode. Due to the
fact that I use MS Visual Studio C++ 2008 Express Edition, I had to open each
solution and compile it separately as some of the projects referenced MFC files
that are not available with the Express Edition. Those issues were corrected in
the shadow and all builds succeeded. Besides
the changes to eliminate MFC references, one additional change was required in
the King Oracle provider project in that the references to Oracle 10 libs were
replaced by the corresponding Oracle 11 ones. Using
the command built.bat –c=release –a=install –o=c:\FdoHome
on the FDO and ThirdParty directory, all DLLs were copied into the specified
folder and hence made accessible to the FDO application. The
providers.xml file was modified to include the following statement for the King
Oracle Provider:
<FeatureProvider>
<Name>King.Oracle.3.5</Name>
<DisplayName>King Provider for Oracle</DisplayName>
<Description>Read/write access to spatial and attribute data
in an Oracle Spatial.</Description>
<IsManaged>False</IsManaged>
<Version>3.5.0.0</Version>
<FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion>
<LibraryPath>.\KingOracleProvider.dll</LibraryPath>
</FeatureProvider> I
did perform some debugging on the code. When following the statement that
retrieves the schema name (see code below), I noted that it does not hit the
function that implements the retrieval of the schema name but ends up in the
function FdoCollection::GetCount() (file FDO\Unmanaged\Inc\Common\Collection.h).
However, following other requests like the apply schema execute or the describe
schema execute call, the correct functions are hit and executed. I also did
some dependency checks on some DLLs and executables and nothing missing was
reported. I
assume that this may be just a simple setup issue but after trying multiple
things now, I reached a point where I am not sure what to try next. If someone
has any suggestions I would appreciate the feedback. Also, if there are
additional questions, please let me know. Thanks
Thomas
FdoPtr<FdoIDescribeSchema> describe_schema_cmd =
(FdoIDescribeSchema*) fdo_connection->CreateCommand(
FdoCommandType_DescribeSchema); FdoFeatureSchemasP
schema_collection = describe_schema_cmd->Execute(); FdoInt32 schema_count
= schema_collection->GetCount(); if (schema_count ==
0)
printf(" -> No schemas found \n"); else for (int
s = 0; s < schema_count; s++) {
FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s);
FdoStringP curr_schema_name = curr_schema->GetName();
printf(" -> Schema[%d]: %ls \n", s, (FdoString
*)curr_schema_name);
FdoPtr<FdoClassCollection> curr_schema_classes =
curr_schema->GetClasses();
FdoInt32 curr_schema_class_count = curr_schema_classes->GetCount();
if (curr_schema_class_count == 0)
printf(" -> No classes found for current schema
\n");
else
for (int sc = 0; sc < curr_schema_class_count; sc++) {
FdoPtr<FdoClassDefinition> curr_schema_class =
curr_schema_classes->GetItem(sc);
FdoStringP curr_schema_class_name = curr_schema_class->GetName();
printf(" -> Class[%d]: %ls \n",
sc,
(FdoString *)curr_schema_class_name);
} // for (int sc = 0; ... } // for (int s = 0; ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Thomas Knoell-2
|
Some javascript/style in this post has been disabled (why?)
Hi Haris, I got by the describe schema issue I had
with the King Oracle provider. Executing the describe schema command after
applying the schema now works fine. One thing that is unpleasant is the fact
that the describe-schema implementation in the provider returns class names for
feature classes that do not match the original class name: the new name is a
combination of data store, class and geometry property name, all concatenated
by a hyphen (for example DB1~MYCLASS~GEOM). That means that the
application needs a provider specific implementation where the original class
name can be mapped to the one the King Oracle provider uses. The link you provided in a previous mail
describes a possibility to define a new class name of an existing geometry
table using a King Oracle meta data table and hence providing a workaround to
the fact that feature class names are altered. I applied this to the feature
classes I created with the apply-schema command but it did not work: rather
than replacing the name (for example) DB1~MYCLASS~GEOM with NewClass,
it actually returns two classes now: DB1~MYCLASS~GEOM and NewClass
(for which no table actually exists). Since the site you point to mentions that
this option is in a BETA release status, I assume that either this may not be
supported yet or I had an incorrect expectation. Could you please comment on
this. There are a couple of other issues with
this meta data table: Ø
I
updated the meta data table from the application after successfully applying
the schema. Unfortunately, to have those changes take effect, I have to close
and re-open the connection. before executing the describe schema command. I
believe this should not be necessary. Ø
Your
site states that non feature classes identified via the meta data table belong
to a schema named KingFdoClass. This is currently not the case as those
classes are listed as members of the schema KingOra. Will this change
for the final release? In my last mail I asked whether or not
you plan to automatically maintain the meta data table if a schema is applied.
Can you please comment on this as well? Thanks Thomas From: [hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi Haris, Thanks for the provided link, that is helpful. I created the table, added the information to the connection
string and executed the test. I noted that the ApplySchema command is not
adding any specified non feature classes to that table. Since the link you
provided indicates that this is in Beta release at this point, is your final
version enhancing your ApplySchema command implementation to automatically
update this table for non feature classes? Thanks Thomas From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic For tables which are
not in sdo_geom_metadata you need to add them using "KingFdoClass"
table (http://www.sl-king.com/fdooracle/KingFdoClass.htm). One reason I can
remember right now for not working, would be because FDO schema is cached. You
would need to restart provider ( there is also non-standard FDO function in
King.Oracle connection). Haris From: [hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi Haris, Here are the answers to your questions: >> How did
you applied schema ? You mention feature and non-feature class ? I executed the apply schema command (see below) from the FDO
application. The schema that is defined and then applied contains a
FdoFeatureClass and FdoClass. The application has to work with data stores that
contain tables with and without spatial information and must be able to
maintain them. That is why the test schema contains both classes. >> You
applied Autodesk schema , metadata tables? The original data store did not contain any tables. However,
since you mentioned it here, I added the f_* tables and tried it again –
same result. >> In
King.Oracle for Oracle Table to become available as FDO class the table has to
be in sdo_geom_metadata . You did that ? >> Of 'course
Oracle user you are using to connect has to see those tables etc... Since the schema was applied with the FdoIApplySchema interface,
this should have been taken care of automatically. I checked and the feature
class table does show up in sdo_geom_metadata. Obviously, the non feature class
does not. And the Oracle user the application is connecting to can see those
tables. So, are you saying that if I connect to an Oracle data store that does
have tables without spatial information, I would not be able to use the
insert/delete/update commands to maintain them when working with the King
Oracle provider? Thanks Thomas
FdoPtr<FdoIApplySchema> apply_schema_cmd =
(FdoIApplySchema*) fdo_connection->CreateCommand(
FdoCommandType_ApplySchema);
FdoPtr<FdoFeatureSchemaCollection> schemas =
FdoFeatureSchemaCollection::Create(NULL);
FdoPtr<FdoFeatureSchema> schema =
FdoFeatureSchema::Create(L"TestSchema", L"Test Schema");
FdoPtr<FdoClassCollection> classes = schema->GetClasses();
printf(" -> Defining feature class fc \n");
FdoPtr<FdoFeatureClass> fc_class = FdoFeatureClass::Create(L"fc",
L"fc");
fc_class->SetIsAbstract(false);
FdoPropertyDefinitionCollection *data_property_definitions =
fc_class->GetProperties();
FdoDataPropertyDefinitionCollection *id_property_definitions =
fc_class->GetIdentityProperties();
FdoDataPropertyDefinition *data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
data_property_definition->SetDataType(FdoDataType_Int64);
data_property_definition->SetNullable(false);
data_property_definition->SetIsAutoGenerated(true);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition); FdoGeometricPropertyDefinition
*geometric_property_definition =
FdoGeometricPropertyDefinition::Create(L"GProp",L"GProp");
geometric_property_definition->SetGeometryTypes(
FdoGeometricType_Point |
FdoGeometricType_Curve |
FdoGeometricType_Surface |
FdoGeometricType_Solid );
geometric_property_definition->SetHasElevation(true);
data_property_definitions->Add(geometric_property_definition);
fc_class->SetGeometryProperty(geometric_property_definition);
FDO_SAFE_RELEASE(geometric_property_definition); FDO_SAFE_RELEASE(id_property_definitions);
FDO_SAFE_RELEASE(data_property_definitions);
fc_class->SetBaseClass(NULL);
classes->Add(fc_class);
printf(" -> Defining non feature class nfc \n");
FdoPtr<FdoClass> nfc_class = FdoClass::Create(L"nfc",
L"nfc");
nfc_class->SetIsAbstract(false);
data_property_definitions = nfc_class->GetProperties();
id_property_definitions = nfc_class->GetIdentityProperties();
data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(false);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition); FDO_SAFE_RELEASE(data_property_definition);
FDO_SAFE_RELEASE(id_property_definitions);
FDO_SAFE_RELEASE(data_property_definitions);
nfc_class->SetBaseClass(NULL);
classes->Add(nfc_class);
schemas->Add(schema);
printf(" -> Applying the schema \n");
apply_schema_cmd->SetFeatureSchema(schema);
apply_schema_cmd->Execute(); From: [hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic How did you applied
schema ? You mention feature and non-feature class ? You applied Autodesk
schema , metadata tables? In King.Oracle for
Oracle Table to become available as FDO class the table has to be in
sdo_geom_metadata . You did that ? Of 'course Oracle
user you are using to connect has to see those tables etc... Haris From: [hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi, I
am working on a FDO based application that should use the King Oracle Provider
to connect to a data source on an Oracle 11g instance. The application
currently connects fine to an empty data store (the data store does not contain
any tables) and successfully applies a test schema that consists of a feature
and a non feature class. The problem arises in the following step where a
describe schema request is executed. In this case, the result is one schema
named KingOra and no classes. I expected the test schema and its
corresponding classes being reported. The
application has access to all the DLLs that come with FDO. The DLLs were
created by compiling the projects from the trunk in release mode. Due to the
fact that I use MS Visual Studio C++ 2008 Express Edition, I had to open each
solution and compile it separately as some of the projects referenced MFC files
that are not available with the Express Edition. Those issues were corrected in
the shadow and all builds succeeded. Besides
the changes to eliminate MFC references, one additional change was required in
the King Oracle provider project in that the references to Oracle 10 libs were
replaced by the corresponding Oracle 11 ones. Using
the command built.bat –c=release –a=install –o=c:\FdoHome
on the FDO and ThirdParty directory, all DLLs were copied into the specified
folder and hence made accessible to the FDO application. The
providers.xml file was modified to include the following statement for the King
Oracle Provider:
<FeatureProvider>
<Name>King.Oracle.3.5</Name>
<DisplayName>King Provider for Oracle</DisplayName>
<Description>Read/write access to spatial and attribute data
in an Oracle Spatial.</Description>
<IsManaged>False</IsManaged>
<Version>3.5.0.0</Version>
<FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion>
<LibraryPath>.\KingOracleProvider.dll</LibraryPath>
</FeatureProvider> I
did perform some debugging on the code. When following the statement that
retrieves the schema name (see code below), I noted that it does not hit the
function that implements the retrieval of the schema name but ends up in the
function FdoCollection::GetCount() (file FDO\Unmanaged\Inc\Common\Collection.h).
However, following other requests like the apply schema execute or the describe
schema execute call, the correct functions are hit and executed. I also did
some dependency checks on some DLLs and executables and nothing missing was
reported. I
assume that this may be just a simple setup issue but after trying multiple
things now, I reached a point where I am not sure what to try next. If someone
has any suggestions I would appreciate the feedback. Also, if there are
additional questions, please let me know. Thanks
Thomas
FdoPtr<FdoIDescribeSchema> describe_schema_cmd =
(FdoIDescribeSchema*) fdo_connection->CreateCommand(
FdoCommandType_DescribeSchema); FdoFeatureSchemasP
schema_collection = describe_schema_cmd->Execute(); FdoInt32 schema_count
= schema_collection->GetCount(); if (schema_count ==
0)
printf(" -> No schemas found \n"); else for (int
s = 0; s < schema_count; s++) {
FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s);
FdoStringP curr_schema_name = curr_schema->GetName();
printf(" -> Schema[%d]: %ls \n", s, (FdoString
*)curr_schema_name);
FdoPtr<FdoClassCollection> curr_schema_classes =
curr_schema->GetClasses();
FdoInt32 curr_schema_class_count = curr_schema_classes->GetCount();
if (curr_schema_class_count == 0)
printf(" -> No classes found for current schema
\n");
else
for (int sc = 0; sc < curr_schema_class_count; sc++) {
FdoPtr<FdoClassDefinition> curr_schema_class =
curr_schema_classes->GetItem(sc);
FdoStringP curr_schema_class_name = curr_schema_class->GetName();
printf(" -> Class[%d]: %ls \n",
sc,
(FdoString *)curr_schema_class_name);
} // for (int sc = 0; ... } // for (int s = 0; ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Haris Kurtagic
|
Some javascript/style in this post has been disabled (why?)
Hi Tomas, Regarding names of FDO classes and
their representation in underlying data store is something which could be pain
but I don't see right solution (other then use of additional metadata to describe
generated name for FDO class). It is not only problem of King.Oracle or rdbms providers
but also files. There are some steps in King.Oracle that could create names of
FDO classes which would more look like original, but no 100% solution. KingFdoClass is metadata table
which works and we use it a lot. You need to add row to it after creating table
in Oracle. Row in KingFdoClass metadata table will not be auto added with apply
schema command. - Schema is cached because of
performance reasons. Right now it is necessary because of extensive use of DescribeSchema
command by current FDO clients. I would much more prefer that schema would not
be cached but right now it would not be practical. - Perhaps we changed something. As
far as I remember it was different schema. - I was thinking about auto-updating
metadata table with apply schema. But there are few scenarios in which it would
not be possible. Also trough our experience of use of provider in our projects
we realized we don't need it. Haris From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi Haris, I got by the
describe schema issue I had with the King Oracle provider. Executing the
describe schema command after applying the schema now works fine. One thing that
is unpleasant is the fact that the describe-schema implementation in the
provider returns class names for feature classes that do not match the original
class name: the new name is a combination of data store, class and geometry
property name, all concatenated by a hyphen (for example DB1~MYCLASS~GEOM).
That means that the application needs a provider specific implementation where
the original class name can be mapped to the one the King Oracle provider uses.
The link you
provided in a previous mail describes a possibility to define a new class name
of an existing geometry table using a King Oracle meta data table and hence
providing a workaround to the fact that feature class names are altered. I
applied this to the feature classes I created with the apply-schema command but
it did not work: rather than replacing the name (for example) DB1~MYCLASS~GEOM
with NewClass, it actually returns two classes now: DB1~MYCLASS~GEOM
and NewClass (for which no table actually exists). Since the site you
point to mentions that this option is in a BETA release status, I assume that
either this may not be supported yet or I had an incorrect expectation. Could
you please comment on this. There are a
couple of other issues with this meta data table: Ø I
updated the meta data table from the application after successfully applying
the schema. Unfortunately, to have those changes take effect, I have to close
and re-open the connection. before executing the describe schema command. I
believe this should not be necessary. Ø Your site
states that non feature classes identified via the meta data table belong to a
schema named KingFdoClass. This is currently not the case as those
classes are listed as members of the schema KingOra. Will this change
for the final release? In my last mail
I asked whether or not you plan to automatically maintain the meta data table
if a schema is applied. Can you please comment on this as well? Thanks Thomas From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi Haris, Thanks for the provided link, that is helpful. I created the table, added the information to the connection
string and executed the test. I noted that the ApplySchema command is not
adding any specified non feature classes to that table. Since the link you
provided indicates that this is in Beta release at this point, is your final
version enhancing your ApplySchema command implementation to automatically
update this table for non feature classes? Thanks Thomas From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic For tables which are not in
sdo_geom_metadata you need to add them using "KingFdoClass" table (http://www.sl-king.com/fdooracle/KingFdoClass.htm). One reason I can remember right
now for not working, would be because FDO schema is cached. You would need to
restart provider ( there is also non-standard FDO function in King.Oracle
connection). Haris From: [hidden email]
[mailto:[hidden email]] On Behalf Of Thomas
Knoell Hi Haris, Here are the answers to your questions: >> How did you applied
schema ? You mention feature and non-feature class ? I executed the apply schema command (see below) from the FDO
application. The schema that is defined and then applied contains a
FdoFeatureClass and FdoClass. The application has to work with data stores that
contain tables with and without spatial information and must be able to
maintain them. That is why the test schema contains both classes. >> You applied Autodesk
schema , metadata tables? The original data store did not contain any tables. However,
since you mentioned it here, I added the f_* tables and tried it again –
same result. >> In King.Oracle for
Oracle Table to become available as FDO class the table has to be in
sdo_geom_metadata . You did that ? >> Of 'course Oracle user
you are using to connect has to see those tables etc... Since the schema was applied with the FdoIApplySchema interface,
this should have been taken care of automatically. I checked and the feature
class table does show up in sdo_geom_metadata. Obviously, the non feature class
does not. And the Oracle user the application is connecting to can see those
tables. So, are you saying that if I connect to an Oracle data store that does
have tables without spatial information, I would not be able to use the
insert/delete/update commands to maintain them when working with the King
Oracle provider? Thanks Thomas
FdoPtr<FdoIApplySchema> apply_schema_cmd =
(FdoIApplySchema*) fdo_connection->CreateCommand(
FdoCommandType_ApplySchema);
FdoPtr<FdoFeatureSchemaCollection> schemas =
FdoFeatureSchemaCollection::Create(NULL);
FdoPtr<FdoFeatureSchema> schema =
FdoFeatureSchema::Create(L"TestSchema", L"Test Schema");
FdoPtr<FdoClassCollection> classes = schema->GetClasses();
printf(" -> Defining feature class fc \n");
FdoPtr<FdoFeatureClass> fc_class = FdoFeatureClass::Create(L"fc",
L"fc");
fc_class->SetIsAbstract(false);
FdoPropertyDefinitionCollection *data_property_definitions =
fc_class->GetProperties();
FdoDataPropertyDefinitionCollection *id_property_definitions =
fc_class->GetIdentityProperties();
FdoDataPropertyDefinition *data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
data_property_definition->SetDataType(FdoDataType_Int64);
data_property_definition->SetNullable(false);
data_property_definition->SetIsAutoGenerated(true);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
FdoGeometricPropertyDefinition *geometric_property_definition =
FdoGeometricPropertyDefinition::Create(L"GProp",L"GProp");
geometric_property_definition->SetGeometryTypes(
FdoGeometricType_Point |
FdoGeometricType_Curve |
FdoGeometricType_Surface |
FdoGeometricType_Solid );
geometric_property_definition->SetHasElevation(true);
data_property_definitions->Add(geometric_property_definition);
fc_class->SetGeometryProperty(geometric_property_definition);
FDO_SAFE_RELEASE(geometric_property_definition);
FDO_SAFE_RELEASE(id_property_definitions);
FDO_SAFE_RELEASE(data_property_definitions);
fc_class->SetBaseClass(NULL);
classes->Add(fc_class);
printf(" -> Defining non feature class nfc \n");
FdoPtr<FdoClass> nfc_class = FdoClass::Create(L"nfc",
L"nfc");
nfc_class->SetIsAbstract(false);
data_property_definitions = nfc_class->GetProperties();
id_property_definitions = nfc_class->GetIdentityProperties();
data_property_definition =
FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(false);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
id_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
data_property_definition =
FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1");
data_property_definition->SetDataType(FdoDataType_Int32);
data_property_definition->SetNullable(true);
data_property_definition->SetIsAutoGenerated(false);
data_property_definitions->Add(data_property_definition);
FDO_SAFE_RELEASE(data_property_definition);
FDO_SAFE_RELEASE(id_property_definitions);
FDO_SAFE_RELEASE(data_property_definitions);
nfc_class->SetBaseClass(NULL);
classes->Add(nfc_class);
schemas->Add(schema);
printf(" -> Applying the schema \n");
apply_schema_cmd->SetFeatureSchema(schema);
apply_schema_cmd->Execute(); From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Haris
Kurtagic How did you applied schema ? You
mention feature and non-feature class ? You applied Autodesk schema , metadata
tables? In King.Oracle for Oracle Table
to become available as FDO class the table has to be in sdo_geom_metadata . You
did that ? Of 'course Oracle user you are
using to connect has to see those tables etc... Haris From:
[hidden email] [mailto:[hidden email]]
On Behalf Of Thomas Knoell Hi, I
am working on a FDO based application that should use the King Oracle Provider
to connect to a data source on an Oracle 11g instance. The application
currently connects fine to an empty data store (the data store does not contain
any tables) and successfully applies a test schema that consists of a feature
and a non feature class. The problem arises in the following step where a
describe schema request is executed. In this case, the result is one schema
named KingOra and no classes. I expected the test schema and its
corresponding classes being reported. The
application has access to all the DLLs that come with FDO. The DLLs were
created by compiling the projects from the trunk in release mode. Due to the
fact that I use MS Visual Studio C++ 2008 Express Edition, I had to open each
solution and compile it separately as some of the projects referenced MFC files
that are not available with the Express Edition. Those issues were corrected in
the shadow and all builds succeeded. Besides
the changes to eliminate MFC references, one additional change was required in
the King Oracle provider project in that the references to Oracle 10 libs were
replaced by the corresponding Oracle 11 ones. Using
the command built.bat –c=release –a=install –o=c:\FdoHome
on the FDO and ThirdParty directory, all DLLs were copied into the specified folder
and hence made accessible to the FDO application. The
providers.xml file was modified to include the following statement for the King
Oracle Provider:
<FeatureProvider>
<Name>King.Oracle.3.5</Name>
<DisplayName>King Provider for Oracle</DisplayName>
<Description>Read/write access to spatial and attribute data
in an Oracle Spatial.</Description>
<IsManaged>False</IsManaged>
<Version>3.5.0.0</Version>
<FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion>
<LibraryPath>.\KingOracleProvider.dll</LibraryPath>
</FeatureProvider> I
did perform some debugging on the code. When following the statement that
retrieves the schema name (see code below), I noted that it does not hit the
function that implements the retrieval of the schema name but ends up in the
function FdoCollection::GetCount() (file FDO\Unmanaged\Inc\Common\Collection.h).
However, following other requests like the apply schema execute or the describe
schema execute call, the correct functions are hit and executed. I also did
some dependency checks on some DLLs and executables and nothing missing was
reported. I
assume that this may be just a simple setup issue but after trying multiple
things now, I reached a point where I am not sure what to try next. If someone
has any suggestions I would appreciate the feedback. Also, if there are
additional questions, please let me know. Thanks
Thomas
FdoPtr<FdoIDescribeSchema> describe_schema_cmd =
(FdoIDescribeSchema*) fdo_connection->CreateCommand(
FdoCommandType_DescribeSchema);
FdoFeatureSchemasP schema_collection = describe_schema_cmd->Execute();
FdoInt32 schema_count = schema_collection->GetCount();
if (schema_count == 0)
printf(" -> No schemas found \n");
else
for (int s = 0; s < schema_count; s++) {
FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s);
FdoStringP curr_schema_name = curr_schema->GetName();
printf(" -> Schema[%d]: %ls \n", s, (FdoString
*)curr_schema_name);
FdoPtr<FdoClassCollection> curr_schema_classes =
curr_schema->GetClasses();
FdoInt32 curr_schema_class_count = curr_schema_classes->GetCount();
if (curr_schema_class_count == 0)
printf(" -> No classes found for current schema
\n");
else
for (int sc = 0; sc < curr_schema_class_count; sc++) {
FdoPtr<FdoClassDefinition> curr_schema_class =
curr_schema_classes->GetItem(sc);
FdoStringP curr_schema_class_name = curr_schema_class->GetName();
printf(" -> Class[%d]: %ls \n",
sc,
(FdoString *)curr_schema_class_name);
} // for (int sc = 0; ...
} // for (int s = 0; ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
zspitzer
|
Wasn't the main reason for this approach tables with multiple geometry columns?
It's a real pain and makes FDO really inconsistant as an abstraction layer... The FDO PostGIS provider does this in a nice transparent fashion http://zacster.blogspot.com/2008/08/some-ponderings-on-fdo-schemas.html z On Tue, Jun 16, 2009 at 8:53 PM, Haris Kurtagic<[hidden email]> wrote: > Hi Tomas, > > > > Regarding names of FDO classes and their representation in underlying data > store is something which could be pain but I don't see right solution (other > then use of additional metadata to describe generated name for FDO class). > It is not only problem of King.Oracle or rdbms providers but also files. > There are some steps in King.Oracle that could create names of FDO classes > which would more look like original, but no 100% solution. > > > > KingFdoClass is metadata table which works and we use it a lot. You need to > add row to it after creating table in Oracle. Row in KingFdoClass metadata > table will not be auto added with apply schema command. > > > > - Schema is cached because of performance reasons. Right now it is necessary > because of extensive use of DescribeSchema command by current FDO clients. I > would much more prefer that schema would not be cached but right now it > would not be practical. > > > > - Perhaps we changed something. As far as I remember it was different > schema. > > > > - I was thinking about auto-updating metadata table with apply schema. But > there are few scenarios in which it would not be possible. Also trough our > experience of use of provider in our projects we realized we don't need it. > > > > Haris > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Thomas Knoell > Sent: Monday, June 15, 2009 9:43 PM > To: 'FDO Internals Mail List' > Subject: RE: [fdo-internals] King Oracle Issue > > > > Hi Haris, > > > > I got by the describe schema issue I had with the King Oracle provider. > Executing the describe schema command after applying the schema now works > fine. > > > > One thing that is unpleasant is the fact that the describe-schema > implementation in the provider returns class names for feature classes that > do not match the original class name: the new name is a combination of data > store, class and geometry property name, all concatenated by a hyphen (for > example DB1~MYCLASS~GEOM). That means that the application needs a provider > specific implementation where the original class name can be mapped to the > one the King Oracle provider uses. > > > > The link you provided in a previous mail describes a possibility to define a > new class name of an existing geometry table using a King Oracle meta data > table and hence providing a workaround to the fact that feature class names > are altered. I applied this to the feature classes I created with the > apply-schema command but it did not work: rather than replacing the name > (for example) DB1~MYCLASS~GEOM with NewClass, it actually returns two > classes now: DB1~MYCLASS~GEOM and NewClass (for which no table actually > exists). Since the site you point to mentions that this option is in a BETA > release status, I assume that either this may not be supported yet or I had > an incorrect expectation. Could you please comment on this. > > > > There are a couple of other issues with this meta data table: > > > > Ø I updated the meta data table from the application after successfully > applying the schema. Unfortunately, to have those changes take effect, I > have to close and re-open the connection. before executing the describe > schema command. I believe this should not be necessary. > > Ø Your site states that non feature classes identified via the meta data > table belong to a schema named KingFdoClass. This is currently not the case > as those classes are listed as members of the schema KingOra. Will this > change for the final release? > > > > In my last mail I asked whether or not you plan to automatically maintain > the meta data table if a schema is applied. Can you please comment on this > as well? > > > > Thanks > > > > Thomas > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Thomas Knoell > Sent: June-10-09 5:21 PM > To: 'FDO Internals Mail List' > Subject: RE: [fdo-internals] King Oracle Issue > > > > Hi Haris, > > > > Thanks for the provided link, that is helpful. > > > > I created the table, added the information to the connection string and > executed the test. I noted that the ApplySchema command is not adding any > specified non feature classes to that table. Since the link you provided > indicates that this is in Beta release at this point, is your final version > enhancing your ApplySchema command implementation to automatically update > this table for non feature classes? > > > > Thanks > > > > Thomas > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Haris Kurtagic > Sent: June-10-09 5:01 PM > To: FDO Internals Mail List > Subject: RE: [fdo-internals] King Oracle Issue > > > > For tables which are not in sdo_geom_metadata you need to add them using > "KingFdoClass" table (http://www.sl-king.com/fdooracle/KingFdoClass.htm). > > > > One reason I can remember right now for not working, would be because FDO > schema is cached. You would need to restart provider ( there is also > non-standard FDO function in King.Oracle connection). > > Haris > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Thomas Knoell > Sent: Wednesday, June 10, 2009 10:13 PM > To: 'FDO Internals Mail List' > Subject: RE: [fdo-internals] King Oracle Issue > > > > Hi Haris, > > > > Here are the answers to your questions: > > > >>> How did you applied schema ? You mention feature and non-feature class ? > > > > I executed the apply schema command (see below) from the FDO application. > The schema that is defined and then applied contains a FdoFeatureClass and > FdoClass. The application has to work with data stores that contain tables > with and without spatial information and must be able to maintain them. That > is why the test schema contains both classes. > > > >>> You applied Autodesk schema , metadata tables? > > > > The original data store did not contain any tables. However, since you > mentioned it here, I added the f_* tables and tried it again – same result. > > > >>> In King.Oracle for Oracle Table to become available as FDO class the >>> table has to be in sdo_geom_metadata . You did that ? > >>> Of 'course Oracle user you are using to connect has to see those tables >>> etc... > > > > Since the schema was applied with the FdoIApplySchema interface, this should > have been taken care of automatically. I checked and the feature class table > does show up in sdo_geom_metadata. Obviously, the non feature class does > not. And the Oracle user the application is connecting to can see those > tables. So, are you saying that if I connect to an Oracle data store that > does have tables without spatial information, I would not be able to use the > insert/delete/update commands to maintain them when working with the King > Oracle provider? > > > > Thanks > > > > Thomas > > > > > > FdoPtr<FdoIApplySchema> apply_schema_cmd = > > (FdoIApplySchema*) fdo_connection->CreateCommand( > > > FdoCommandType_ApplySchema); > > FdoPtr<FdoFeatureSchemaCollection> schemas = > > > FdoFeatureSchemaCollection::Create(NULL); > > FdoPtr<FdoFeatureSchema> schema = > > FdoFeatureSchema::Create(L"TestSchema", L"Test Schema"); > > FdoPtr<FdoClassCollection> classes = schema->GetClasses(); > > > > printf(" -> Defining feature class fc \n"); > > > > FdoPtr<FdoFeatureClass> fc_class = FdoFeatureClass::Create(L"fc", > L"fc"); > > fc_class->SetIsAbstract(false); > > > > FdoPropertyDefinitionCollection *data_property_definitions = > > > fc_class->GetProperties(); > > FdoDataPropertyDefinitionCollection *id_property_definitions = > > > fc_class->GetIdentityProperties(); > > > > FdoDataPropertyDefinition *data_property_definition = > > FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp"); > > data_property_definition->SetDataType(FdoDataType_Int64); > > data_property_definition->SetNullable(false); > > data_property_definition->SetIsAutoGenerated(true); > > data_property_definitions->Add(data_property_definition); > > id_property_definitions->Add(data_property_definition); > > FDO_SAFE_RELEASE(data_property_definition); > > > > data_property_definition = > > FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1"); > > data_property_definition->SetDataType(FdoDataType_Int32); > > data_property_definition->SetNullable(true); > > data_property_definition->SetIsAutoGenerated(false); > > data_property_definitions->Add(data_property_definition); > > FDO_SAFE_RELEASE(data_property_definition); > > > > FdoGeometricPropertyDefinition *geometric_property_definition = > > > FdoGeometricPropertyDefinition::Create(L"GProp",L"GProp"); > > geometric_property_definition->SetGeometryTypes( > > FdoGeometricType_Point | > > FdoGeometricType_Curve | > > FdoGeometricType_Surface | > > FdoGeometricType_Solid > ); > > geometric_property_definition->SetHasElevation(true); > > data_property_definitions->Add(geometric_property_definition); > > fc_class->SetGeometryProperty(geometric_property_definition); > > FDO_SAFE_RELEASE(geometric_property_definition); > > FDO_SAFE_RELEASE(id_property_definitions); > > FDO_SAFE_RELEASE(data_property_definitions); > > > > fc_class->SetBaseClass(NULL); > > classes->Add(fc_class); > > > > printf(" -> Defining non feature class nfc \n"); > > > > FdoPtr<FdoClass> nfc_class = FdoClass::Create(L"nfc", L"nfc"); > > nfc_class->SetIsAbstract(false); > > > > data_property_definitions = nfc_class->GetProperties(); > > id_property_definitions = nfc_class->GetIdentityProperties(); > > > > data_property_definition = > > FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp"); > > data_property_definition->SetDataType(FdoDataType_Int32); > > data_property_definition->SetNullable(false); > > data_property_definition->SetIsAutoGenerated(false); > > data_property_definitions->Add(data_property_definition); > > id_property_definitions->Add(data_property_definition); > > FDO_SAFE_RELEASE(data_property_definition); > > > > data_property_definition = > > FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1"); > > data_property_definition->SetDataType(FdoDataType_Int32); > > data_property_definition->SetNullable(true); > > data_property_definition->SetIsAutoGenerated(false); > > data_property_definitions->Add(data_property_definition); > > FDO_SAFE_RELEASE(data_property_definition); > > FDO_SAFE_RELEASE(id_property_definitions); > > FDO_SAFE_RELEASE(data_property_definitions); > > > > nfc_class->SetBaseClass(NULL); > > classes->Add(nfc_class); > > > > schemas->Add(schema); > > > > printf(" -> Applying the schema \n"); > > apply_schema_cmd->SetFeatureSchema(schema); > > apply_schema_cmd->Execute(); > > > > > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Haris Kurtagic > Sent: June-10-09 3:28 PM > To: FDO Internals Mail List > Subject: RE: [fdo-internals] King Oracle Issue > > > > How did you applied schema ? You mention feature and non-feature class ? You > applied Autodesk schema , metadata tables? > > > > In King.Oracle for Oracle Table to become available as FDO class the table > has to be in sdo_geom_metadata . You did that ? > > Of 'course Oracle user you are using to connect has to see those tables > etc... > > > > Haris > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Thomas Knoell > Sent: Wednesday, June 10, 2009 8:42 PM > To: [hidden email] > Subject: [fdo-internals] King Oracle Issue > > > > Hi, > > > > I am working on a FDO based application that should use the King Oracle > Provider to connect to a data source on an Oracle 11g instance. The > application currently connects fine to an empty data store (the data store > does not contain any tables) and successfully applies a test schema that > consists of a feature and a non feature class. The problem arises in the > following step where a describe schema request is executed. In this case, > the result is one schema named KingOra and no classes. I expected the test > schema and its corresponding classes being reported. > > > > The application has access to all the DLLs that come with FDO. The DLLs were > created by compiling the projects from the trunk in release mode. Due to the > fact that I use MS Visual Studio C++ 2008 Express Edition, I had to open > each solution and compile it separately as some of the projects referenced > MFC files that are not available with the Express Edition. Those issues were > corrected in the shadow and all builds succeeded. > > > > Besides the changes to eliminate MFC references, one additional change was > required in the King Oracle provider project in that the references to > Oracle 10 libs were replaced by the corresponding Oracle 11 ones. > > > > Using the command built.bat –c=release –a=install –o=c:\FdoHome on the FDO > and ThirdParty directory, all DLLs were copied into the specified folder and > hence made accessible to the FDO application. > > > > The providers.xml file was modified to include the following statement for > the King Oracle Provider: > > > > <FeatureProvider> > > <Name>King.Oracle.3.5</Name> > > <DisplayName>King Provider for Oracle</DisplayName> > > <Description>Read/write access to spatial and attribute data in an > Oracle Spatial.</Description> > > <IsManaged>False</IsManaged> > > <Version>3.5.0.0</Version> > > <FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion> > > <LibraryPath>.\KingOracleProvider.dll</LibraryPath> > > </FeatureProvider> > > > > I did perform some debugging on the code. When following the statement that > retrieves the schema name (see code below), I noted that it does not hit the > function that implements the retrieval of the schema name but ends up in the > function FdoCollection::GetCount() (file > FDO\Unmanaged\Inc\Common\Collection.h). However, following other requests > like the apply schema execute or the describe schema execute call, the > correct functions are hit and executed. I also did some dependency checks on > some DLLs and executables and nothing missing was reported. > > > > I assume that this may be just a simple setup issue but after trying > multiple things now, I reached a point where I am not sure what to try next. > If someone has any suggestions I would appreciate the feedback. Also, if > there are additional questions, please let me know. > > > > Thanks > > > > Thomas > > > > > > > > FdoPtr<FdoIDescribeSchema> describe_schema_cmd = > > (FdoIDescribeSchema*) fdo_connection->CreateCommand( > > > FdoCommandType_DescribeSchema); > > FdoFeatureSchemasP schema_collection = describe_schema_cmd->Execute(); > > FdoInt32 schema_count = schema_collection->GetCount(); > > if (schema_count == 0) > > printf(" -> No schemas found \n"); > > else > > for (int s = 0; s < schema_count; s++) { > > > > FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s); > > FdoStringP curr_schema_name = curr_schema->GetName(); > > printf(" -> Schema[%d]: %ls \n", s, (FdoString > *)curr_schema_name); > > FdoPtr<FdoClassCollection> curr_schema_classes = > > curr_schema->GetClasses(); > > FdoInt32 curr_schema_class_count = > curr_schema_classes->GetCount(); > > if (curr_schema_class_count == 0) > > printf(" -> No classes found for current schema \n"); > > else > > for (int sc = 0; sc < curr_schema_class_count; sc++) { > > > > FdoPtr<FdoClassDefinition> curr_schema_class = > > > curr_schema_classes->GetItem(sc); > > FdoStringP curr_schema_class_name = > curr_schema_class->GetName(); > > printf(" -> Class[%d]: %ls \n", > > sc, > > (FdoString *)curr_schema_class_name); > > > > } // for (int sc = 0; ... > > > > } // for (int s = 0; ... > > > > > > _______________________________________________ > fdo-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/fdo-internals > > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Haris Kurtagic
|
If I understood correctly ticket PostGIS provider will set FDO class name same as table name.
That logic alone is not enough if there are multiple tables with same name in different Postgre Schemas. As you mentioned, there is also case with more than one geometry column in table. I read your blog post. In point 4. you wrote "Coz if the are multiple geometries, FDO requires to know which one is the identifier". That is not case for King.Oracle, ~column_name name is just about generating unique name inside one FDO schema. Provider uses different way to know which Oracle schema, table name and column name are used for that particular FDO class. I read also email thread and see that many don't like how is naming done (using metadata table it can be done in any way you want). Perhaps I should change something ( I am not fan of '~' character but I am fan of consistent and accurate). I could change that in cases where is only one Oracle table name then I will use that name for like: OracleSchema.OracleTable == KingOra.OracleTable but in some cases will be like: OracleSchema.OracleTable == KingOra.OracleTable AnotherOracleSchema.OracleTable == KingOra.OracleTable_2 or in case of multiple geometries: OracleSchema.OracleTable.Geometry1 == KingOra.OracleTable OracleSchema.OracleTable.Geometry2 == KingOra.OracleTable_2 AnotherOracleSchema.OracleTable == KingOra.OracleTable_3 But there could be another problem with this approach. Name of FDO class representing particular Oracle table could be different depending of connection properties. Good reason for using unique OracleSchema~OracleTable for FDO class and reason is that no meter what connection properties you use to connect to Oracle, you know that you are accessing particular Oracle physical table. Still there would be inconsistency across providers because of FDO Schema Names. I believe inconsistency can come also from allowed characters in filenames and table names. I think, that only way to do across providers it is to have additional metadata. But that is something we don't like in many cases. Haris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Zac Spitzer Sent: Wednesday, June 17, 2009 4:24 AM To: FDO Internals Mail List Subject: Re: [fdo-internals] King Oracle Issue Wasn't the main reason for this approach tables with multiple geometry columns? It's a real pain and makes FDO really inconsistant as an abstraction layer... The FDO PostGIS provider does this in a nice transparent fashion http://zacster.blogspot.com/2008/08/some-ponderings-on-fdo-schemas.html z On Tue, Jun 16, 2009 at 8:53 PM, Haris Kurtagic<[hidden email]> wrote: > Hi Tomas, > > > > Regarding names of FDO classes and their representation in underlying data > store is something which could be pain but I don't see right solution (other > then use of additional metadata to describe generated name for FDO class). > It is not only problem of King.Oracle or rdbms providers but also files. > There are some steps in King.Oracle that could create names of FDO classes > which would more look like original, but no 100% solution. > > > > KingFdoClass is metadata table which works and we use it a lot. You need to > add row to it after creating table in Oracle. Row in KingFdoClass metadata > table will not be auto added with apply schema command. > > > > - Schema is cached because of performance reasons. Right now it is necessary > because of extensive use of DescribeSchema command by current FDO clients. I > would much more prefer that schema would not be cached but right now it > would not be practical. > > > > - Perhaps we changed something. As far as I remember it was different > schema. > > > > - I was thinking about auto-updating metadata table with apply schema. But > there are few scenarios in which it would not be possible. Also trough our > experience of use of provider in our projects we realized we don't need it. > > > > Haris > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Thomas Knoell > Sent: Monday, June 15, 2009 9:43 PM > To: 'FDO Internals Mail List' > Subject: RE: [fdo-internals] King Oracle Issue > > > > Hi Haris, > > > > I got by the describe schema issue I had with the King Oracle provider. > Executing the describe schema command after applying the schema now works > fine. > > > > One thing that is unpleasant is the fact that the describe-schema > implementation in the provider returns class names for feature classes that > do not match the original class name: the new name is a combination of data > store, class and geometry property name, all concatenated by a hyphen (for > example DB1~MYCLASS~GEOM). That means that the application needs a provider > specific implementation where the original class name can be mapped to the > one the King Oracle provider uses. > > > > The link you provided in a previous mail describes a possibility to define a > new class name of an existing geometry table using a King Oracle meta data > table and hence providing a workaround to the fact that feature class names > are altered. I applied this to the feature classes I created with the > apply-schema command but it did not work: rather than replacing the name > (for example) DB1~MYCLASS~GEOM with NewClass, it actually returns two > classes now: DB1~MYCLASS~GEOM and NewClass (for which no table actually > exists). Since the site you point to mentions that this option is in a BETA > release status, I assume that either this may not be supported yet or I had > an incorrect expectation. Could you please comment on this. > > > > There are a couple of other issues with this meta data table: > > > > Ø I updated the meta data table from the application after successfully > applying the schema. Unfortunately, to have those changes take effect, I > have to close and re-open the connection. before executing the describe > schema command. I believe this should not be necessary. > > Ø Your site states that non feature classes identified via the meta data > table belong to a schema named KingFdoClass. This is currently not the case > as those classes are listed as members of the schema KingOra. Will this > change for the final release? > > > > In my last mail I asked whether or not you plan to automatically maintain > the meta data table if a schema is applied. Can you please comment on this > as well? > > > > Thanks > > > > Thomas > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Thomas Knoell > Sent: June-10-09 5:21 PM > To: 'FDO Internals Mail List' > Subject: RE: [fdo-internals] King Oracle Issue > > > > Hi Haris, > > > > Thanks for the provided link, that is helpful. > > > > I created the table, added the information to the connection string and > executed the test. I noted that the ApplySchema command is not adding any > specified non feature classes to that table. Since the link you provided > indicates that this is in Beta release at this point, is your final version > enhancing your ApplySchema command implementation to automatically update > this table for non feature classes? > > > > Thanks > > > > Thomas > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Haris Kurtagic > Sent: June-10-09 5:01 PM > To: FDO Internals Mail List > Subject: RE: [fdo-internals] King Oracle Issue > > > > For tables which are not in sdo_geom_metadata you need to add them using > "KingFdoClass" table (http://www.sl-king.com/fdooracle/KingFdoClass.htm). > > > > One reason I can remember right now for not working, would be because FDO > schema is cached. You would need to restart provider ( there is also > non-standard FDO function in King.Oracle connection). > > Haris > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Thomas Knoell > Sent: Wednesday, June 10, 2009 10:13 PM > To: 'FDO Internals Mail List' > Subject: RE: [fdo-internals] King Oracle Issue > > > > Hi Haris, > > > > Here are the answers to your questions: > > > >>> How did you applied schema ? You mention feature and non-feature class ? > > > > I executed the apply schema command (see below) from the FDO application. > The schema that is defined and then applied contains a FdoFeatureClass and > FdoClass. The application has to work with data stores that contain tables > with and without spatial information and must be able to maintain them. That > is why the test schema contains both classes. > > > >>> You applied Autodesk schema , metadata tables? > > > > The original data store did not contain any tables. However, since you > mentioned it here, I added the f_* tables and tried it again - same result. > > > >>> In King.Oracle for Oracle Table to become available as FDO class the >>> table has to be in sdo_geom_metadata . You did that ? > >>> Of 'course Oracle user you are using to connect has to see those tables >>> etc... > > > > Since the schema was applied with the FdoIApplySchema interface, this should > have been taken care of automatically. I checked and the feature class table > does show up in sdo_geom_metadata. Obviously, the non feature class does > not. And the Oracle user the application is connecting to can see those > tables. So, are you saying that if I connect to an Oracle data store that > does have tables without spatial information, I would not be able to use the > insert/delete/update commands to maintain them when working with the King > Oracle provider? > > > > Thanks > > > > Thomas > > > > > > FdoPtr<FdoIApplySchema> apply_schema_cmd = > > (FdoIApplySchema*) fdo_connection->CreateCommand( > > > FdoCommandType_ApplySchema); > > FdoPtr<FdoFeatureSchemaCollection> schemas = > > > FdoFeatureSchemaCollection::Create(NULL); > > FdoPtr<FdoFeatureSchema> schema = > > FdoFeatureSchema::Create(L"TestSchema", L"Test Schema"); > > FdoPtr<FdoClassCollection> classes = schema->GetClasses(); > > > > printf(" -> Defining feature class fc \n"); > > > > FdoPtr<FdoFeatureClass> fc_class = FdoFeatureClass::Create(L"fc", > L"fc"); > > fc_class->SetIsAbstract(false); > > > > FdoPropertyDefinitionCollection *data_property_definitions = > > > fc_class->GetProperties(); > > FdoDataPropertyDefinitionCollection *id_property_definitions = > > > fc_class->GetIdentityProperties(); > > > > FdoDataPropertyDefinition *data_property_definition = > > FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp"); > > data_property_definition->SetDataType(FdoDataType_Int64); > > data_property_definition->SetNullable(false); > > data_property_definition->SetIsAutoGenerated(true); > > data_property_definitions->Add(data_property_definition); > > id_property_definitions->Add(data_property_definition); > > FDO_SAFE_RELEASE(data_property_definition); > > > > data_property_definition = > > FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1"); > > data_property_definition->SetDataType(FdoDataType_Int32); > > data_property_definition->SetNullable(true); > > data_property_definition->SetIsAutoGenerated(false); > > data_property_definitions->Add(data_property_definition); > > FDO_SAFE_RELEASE(data_property_definition); > > > > FdoGeometricPropertyDefinition *geometric_property_definition = > > > FdoGeometricPropertyDefinition::Create(L"GProp",L"GProp"); > > geometric_property_definition->SetGeometryTypes( > > FdoGeometricType_Point | > > FdoGeometricType_Curve | > > FdoGeometricType_Surface | > > FdoGeometricType_Solid > ); > > geometric_property_definition->SetHasElevation(true); > > data_property_definitions->Add(geometric_property_definition); > > fc_class->SetGeometryProperty(geometric_property_definition); > > FDO_SAFE_RELEASE(geometric_property_definition); > > FDO_SAFE_RELEASE(id_property_definitions); > > FDO_SAFE_RELEASE(data_property_definitions); > > > > fc_class->SetBaseClass(NULL); > > classes->Add(fc_class); > > > > printf(" -> Defining non feature class nfc \n"); > > > > FdoPtr<FdoClass> nfc_class = FdoClass::Create(L"nfc", L"nfc"); > > nfc_class->SetIsAbstract(false); > > > > data_property_definitions = nfc_class->GetProperties(); > > id_property_definitions = nfc_class->GetIdentityProperties(); > > > > data_property_definition = > > FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp"); > > data_property_definition->SetDataType(FdoDataType_Int32); > > data_property_definition->SetNullable(false); > > data_property_definition->SetIsAutoGenerated(false); > > data_property_definitions->Add(data_property_definition); > > id_property_definitions->Add(data_property_definition); > > FDO_SAFE_RELEASE(data_property_definition); > > > > data_property_definition = > > FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1"); > > data_property_definition->SetDataType(FdoDataType_Int32); > > data_property_definition->SetNullable(true); > > data_property_definition->SetIsAutoGenerated(false); > > data_property_definitions->Add(data_property_definition); > > FDO_SAFE_RELEASE(data_property_definition); > > FDO_SAFE_RELEASE(id_property_definitions); > > FDO_SAFE_RELEASE(data_property_definitions); > > > > nfc_class->SetBaseClass(NULL); > > classes->Add(nfc_class); > > > > schemas->Add(schema); > > > > printf(" -> Applying the schema \n"); > > apply_schema_cmd->SetFeatureSchema(schema); > > apply_schema_cmd->Execute(); > > > > > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Haris Kurtagic > Sent: June-10-09 3:28 PM > To: FDO Internals Mail List > Subject: RE: [fdo-internals] King Oracle Issue > > > > How did you applied schema ? You mention feature and non-feature class ? You > applied Autodesk schema , metadata tables? > > > > In King.Oracle for Oracle Table to become available as FDO class the table > has to be in sdo_geom_metadata . You did that ? > > Of 'course Oracle user you are using to connect has to see those tables > etc... > > > > Haris > > > > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Thomas Knoell > Sent: Wednesday, June 10, 2009 8:42 PM > To: [hidden email] > Subject: [fdo-internals] King Oracle Issue > > > > Hi, > > > > I am working on a FDO based application that should use the King Oracle > Provider to connect to a data source on an Oracle 11g instance. The > application currently connects fine to an empty data store (the data store > does not contain any tables) and successfully applies a test schema that > consists of a feature and a non feature class. The problem arises in the > following step where a describe schema request is executed. In this case, > the result is one schema named KingOra and no classes. I expected the test > schema and its corresponding classes being reported. > > > > The application has access to all the DLLs that come with FDO. The DLLs were > created by compiling the projects from the trunk in release mode. Due to the > fact that I use MS Visual Studio C++ 2008 Express Edition, I had to open > each solution and compile it separately as some of the projects referenced > MFC files that are not available with the Express Edition. Those issues were > corrected in the shadow and all builds succeeded. > > > > Besides the changes to eliminate MFC references, one additional change was > required in the King Oracle provider project in that the references to > Oracle 10 libs were replaced by the corresponding Oracle 11 ones. > > > > Using the command built.bat -c=release -a=install -o=c:\FdoHome on the FDO > and ThirdParty directory, all DLLs were copied into the specified folder and > hence made accessible to the FDO application. > > > > The providers.xml file was modified to include the following statement for > the King Oracle Provider: > > > > <FeatureProvider> > > <Name>King.Oracle.3.5</Name> > > <DisplayName>King Provider for Oracle</DisplayName> > > <Description>Read/write access to spatial and attribute data in an > Oracle Spatial.</Description> > > <IsManaged>False</IsManaged> > > <Version>3.5.0.0</Version> > > <FeatureDataObjectsVersion>3.5.0.0</FeatureDataObjectsVersion> > > <LibraryPath>.\KingOracleProvider.dll</LibraryPath> > > </FeatureProvider> > > > > I did perform some debugging on the code. When following the statement that > retrieves the schema name (see code below), I noted that it does not hit the > function that implements the retrieval of the schema name but ends up in the > function FdoCollection::GetCount() (file > FDO\Unmanaged\Inc\Common\Collection.h). However, following other requests > like the apply schema execute or the describe schema execute call, the > correct functions are hit and executed. I also did some dependency checks on > some DLLs and executables and nothing missing was reported. > > > > I assume that this may be just a simple setup issue but after trying > multiple things now, I reached a point where I am not sure what to try next. > If someone has any suggestions I would appreciate the feedback. Also, if > there are additional questions, please let me know. > > > > Thanks > > > > Thomas > > > > > > > > FdoPtr<FdoIDescribeSchema> describe_schema_cmd = > > (FdoIDescribeSchema*) fdo_connection->CreateCommand( > > > FdoCommandType_DescribeSchema); > > FdoFeatureSchemasP schema_collection = describe_schema_cmd->Execute(); > > FdoInt32 schema_count = schema_collection->GetCount(); > > if (schema_count == 0) > > printf(" -> No schemas found \n"); > > else > > for (int s = 0; s < schema_count; s++) { > > > > FdoFeatureSchemaP curr_schema = schema_collection->GetItem(s); > > FdoStringP curr_schema_name = curr_schema->GetName(); > > printf(" -> Schema[%d]: %ls \n", s, (FdoString > *)curr_schema_name); > > FdoPtr<FdoClassCollection> curr_schema_classes = > > curr_schema->GetClasses(); > > FdoInt32 curr_schema_class_count = > curr_schema_classes->GetCount(); > > if (curr_schema_class_count == 0) > > printf(" -> No classes found for current schema \n"); > > else > > for (int sc = 0; sc < curr_schema_class_count; sc++) { > > > > FdoPtr<FdoClassDefinition> curr_schema_class = > > > curr_schema_classes->GetItem(sc); > > FdoStringP curr_schema_class_name = > curr_schema_class->GetName(); > > printf(" -> Class[%d]: %ls \n", > > sc, > > (FdoString *)curr_schema_class_name); > > > > } // for (int sc = 0; ... > > > > } // for (int s = 0; ... > > > > > > _______________________________________________ > fdo-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/fdo-internals > > -- Zac Spitzer - http://zacster.blogspot.com +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
zspitzer
|
On Wed, Jun 17, 2009 at 6:32 PM, Haris Kurtagic<[hidden email]> wrote:
> If I understood correctly ticket PostGIS provider will set FDO class name same as table name. > That logic alone is not enough if there are multiple tables with same name in different Postgre Schemas. simply using use the database schema rather than kingOra solves that problem? > As you mentioned, there is also case with more than one geometry column in table. > > I read your blog post. In point 4. you wrote "Coz if the are multiple geometries, FDO requires > to know which one is the identifier". That is not case for King.Oracle, ~column_name name is just about generating unique name inside one FDO schema. Provider uses different way to know which Oracle schema, table name and column name are used for that particular FDO class. > > I read also email thread and see that many don't like how is naming done (using metadata table it can be done in any way you want). Perhaps I should change something ( I am not fan of '~' character but I am fan of consistent and accurate). > > I could change that in cases where is only one Oracle table name then I will use that name for > like: OracleSchema.OracleTable == KingOra.OracleTable or OracleSchema.OracleTable FDO Schema=OracleSchema FDO Class=OracleTable > But there could be another problem with this approach. Name of FDO class representing particular Oracle table could be different depending of connection properties. Good reason for using unique OracleSchema~OracleTable for FDO class and reason is that no meter what connection properties you use to connect to Oracle, you know that you are accessing particular Oracle physical table. my understanding is that oracle handles this transparently with pooling and with mapguide different connection strings, mean you would be using a different featuresource which is the only level where caching starts? > > Still there would be inconsistency across providers because of FDO Schema Names. I believe inconsistency can come also from allowed characters in filenames and table names. > > I think, that only way to do across providers it is to have additional metadata. But that is something we don't like in many cases. > > Haris > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Zac Spitzer > Sent: Wednesday, June 17, 2009 4:24 AM > To: FDO Internals Mail List > Subject: Re: [fdo-internals] King Oracle Issue > > Wasn't the main reason for this approach tables with multiple geometry columns? > > It's a real pain and makes FDO really inconsistant as an abstraction layer... > > The FDO PostGIS provider does this in a nice transparent fashion > > http://zacster.blogspot.com/2008/08/some-ponderings-on-fdo-schemas.html > > z > > > > On Tue, Jun 16, 2009 at 8:53 PM, Haris Kurtagic<[hidden email]> wrote: >> Hi Tomas, >> >> >> >> Regarding names of FDO classes and their representation in underlying data >> store is something which could be pain but I don't see right solution (other >> then use of additional metadata to describe generated name for FDO class). >> It is not only problem of King.Oracle or rdbms providers but also files. >> There are some steps in King.Oracle that could create names of FDO classes >> which would more look like original, but no 100% solution. >> >> >> >> KingFdoClass is metadata table which works and we use it a lot. You need to >> add row to it after creating table in Oracle. Row in KingFdoClass metadata >> table will not be auto added with apply schema command. >> >> >> >> - Schema is cached because of performance reasons. Right now it is necessary >> because of extensive use of DescribeSchema command by current FDO clients. I >> would much more prefer that schema would not be cached but right now it >> would not be practical. >> >> >> >> - Perhaps we changed something. As far as I remember it was different >> schema. >> >> >> >> - I was thinking about auto-updating metadata table with apply schema. But >> there are few scenarios in which it would not be possible. Also trough our >> experience of use of provider in our projects we realized we don't need it. >> >> >> >> Haris >> >> >> >> From: [hidden email] >> [mailto:[hidden email]] On Behalf Of Thomas Knoell >> Sent: Monday, June 15, 2009 9:43 PM >> To: 'FDO Internals Mail List' >> Subject: RE: [fdo-internals] King Oracle Issue >> >> >> >> Hi Haris, >> >> >> >> I got by the describe schema issue I had with the King Oracle provider. >> Executing the describe schema command after applying the schema now works >> fine. >> >> >> >> One thing that is unpleasant is the fact that the describe-schema >> implementation in the provider returns class names for feature classes that >> do not match the original class name: the new name is a combination of data >> store, class and geometry property name, all concatenated by a hyphen (for >> example DB1~MYCLASS~GEOM). That means that the application needs a provider >> specific implementation where the original class name can be mapped to the >> one the King Oracle provider uses. >> >> >> >> The link you provided in a previous mail describes a possibility to define a >> new class name of an existing geometry table using a King Oracle meta data >> table and hence providing a workaround to the fact that feature class names >> are altered. I applied this to the feature classes I created with the >> apply-schema command but it did not work: rather than replacing the name >> (for example) DB1~MYCLASS~GEOM with NewClass, it actually returns two >> classes now: DB1~MYCLASS~GEOM and NewClass (for which no table actually >> exists). Since the site you point to mentions that this option is in a BETA >> release status, I assume that either this may not be supported yet or I had >> an incorrect expectation. Could you please comment on this. >> >> >> >> There are a couple of other issues with this meta data table: >> >> >> >> Ø I updated the meta data table from the application after successfully >> applying the schema. Unfortunately, to have those changes take effect, I >> have to close and re-open the connection. before executing the describe >> schema command. I believe this should not be necessary. >> >> Ø Your site states that non feature classes identified via the meta data >> table belong to a schema named KingFdoClass. This is currently not the case >> as those classes are listed as members of the schema KingOra. Will this >> change for the final release? >> >> >> >> In my last mail I asked whether or not you plan to automatically maintain >> the meta data table if a schema is applied. Can you please comment on this >> as well? >> >> >> >> Thanks >> >> >> >> Thomas >> >> >> >> From: [hidden email] >> [mailto:[hidden email]] On Behalf Of Thomas Knoell >> Sent: June-10-09 5:21 PM >> To: 'FDO Internals Mail List' >> Subject: RE: [fdo-internals] King Oracle Issue >> >> >> >> Hi Haris, >> >> >> >> Thanks for the provided link, that is helpful. >> >> >> >> I created the table, added the information to the connection string and >> executed the test. I noted that the ApplySchema command is not adding any >> specified non feature classes to that table. Since the link you provided >> indicates that this is in Beta release at this point, is your final version >> enhancing your ApplySchema command implementation to automatically update >> this table for non feature classes? >> >> >> >> Thanks >> >> >> >> Thomas >> >> >> >> From: [hidden email] >> [mailto:[hidden email]] On Behalf Of Haris Kurtagic >> Sent: June-10-09 5:01 PM >> To: FDO Internals Mail List >> Subject: RE: [fdo-internals] King Oracle Issue >> >> >> >> For tables which are not in sdo_geom_metadata you need to add them using >> "KingFdoClass" table (http://www.sl-king.com/fdooracle/KingFdoClass.htm). >> >> >> >> One reason I can remember right now for not working, would be because FDO >> schema is cached. You would need to restart provider ( there is also >> non-standard FDO function in King.Oracle connection). >> >> Haris >> >> >> >> From: [hidden email] >> [mailto:[hidden email]] On Behalf Of Thomas Knoell >> Sent: Wednesday, June 10, 2009 10:13 PM >> To: 'FDO Internals Mail List' >> Subject: RE: [fdo-internals] King Oracle Issue >> >> >> >> Hi Haris, >> >> >> >> Here are the answers to your questions: >> >> >> >>>> How did you applied schema ? You mention feature and non-feature class ? >> >> >> >> I executed the apply schema command (see below) from the FDO application. >> The schema that is defined and then applied contains a FdoFeatureClass and >> FdoClass. The application has to work with data stores that contain tables >> with and without spatial information and must be able to maintain them. That >> is why the test schema contains both classes. >> >> >> >>>> You applied Autodesk schema , metadata tables? >> >> >> >> The original data store did not contain any tables. However, since you >> mentioned it here, I added the f_* tables and tried it again - same result. >> >> >> >>>> In King.Oracle for Oracle Table to become available as FDO class the >>>> table has to be in sdo_geom_metadata . You did that ? >> >>>> Of 'course Oracle user you are using to connect has to see those tables >>>> etc... >> >> >> >> Since the schema was applied with the FdoIApplySchema interface, this should >> have been taken care of automatically. I checked and the feature class table >> does show up in sdo_geom_metadata. Obviously, the non feature class does >> not. And the Oracle user the application is connecting to can see those >> tables. So, are you saying that if I connect to an Oracle data store that >> does have tables without spatial information, I would not be able to use the >> insert/delete/update commands to maintain them when working with the King >> Oracle provider? >> >> >> >> Thanks >> >> >> >> Thomas >> >> >> >> >> >> FdoPtr<FdoIApplySchema> apply_schema_cmd = >> >> (FdoIApplySchema*) fdo_connection->CreateCommand( >> >> >> FdoCommandType_ApplySchema); >> >> FdoPtr<FdoFeatureSchemaCollection> schemas = >> >> >> FdoFeatureSchemaCollection::Create(NULL); >> >> FdoPtr<FdoFeatureSchema> schema = >> >> FdoFeatureSchema::Create(L"TestSchema", L"Test Schema"); >> >> FdoPtr<FdoClassCollection> classes = schema->GetClasses(); >> >> >> >> printf(" -> Defining feature class fc \n"); >> >> >> >> FdoPtr<FdoFeatureClass> fc_class = FdoFeatureClass::Create(L"fc", >> L"fc"); >> >> fc_class->SetIsAbstract(false); >> >> >> >> FdoPropertyDefinitionCollection *data_property_definitions = >> >> >> fc_class->GetProperties(); >> >> FdoDataPropertyDefinitionCollection *id_property_definitions = >> >> >> fc_class->GetIdentityProperties(); >> >> >> >> FdoDataPropertyDefinition *data_property_definition = >> >> FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp"); >> >> data_property_definition->SetDataType(FdoDataType_Int64); >> >> data_property_definition->SetNullable(false); >> >> data_property_definition->SetIsAutoGenerated(true); >> >> data_property_definitions->Add(data_property_definition); >> >> id_property_definitions->Add(data_property_definition); >> >> FDO_SAFE_RELEASE(data_property_definition); >> >> >> >> data_property_definition = >> >> FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1"); >> >> data_property_definition->SetDataType(FdoDataType_Int32); >> >> data_property_definition->SetNullable(true); >> >> data_property_definition->SetIsAutoGenerated(false); >> >> data_property_definitions->Add(data_property_definition); >> >> FDO_SAFE_RELEASE(data_property_definition); >> >> >> >> FdoGeometricPropertyDefinition *geometric_property_definition = >> >> >> FdoGeometricPropertyDefinition::Create(L"GProp",L"GProp"); >> >> geometric_property_definition->SetGeometryTypes( >> >> FdoGeometricType_Point | >> >> FdoGeometricType_Curve | >> >> FdoGeometricType_Surface | >> >> FdoGeometricType_Solid >> ); >> >> geometric_property_definition->SetHasElevation(true); >> >> data_property_definitions->Add(geometric_property_definition); >> >> fc_class->SetGeometryProperty(geometric_property_definition); >> >> FDO_SAFE_RELEASE(geometric_property_definition); >> >> FDO_SAFE_RELEASE(id_property_definitions); >> >> FDO_SAFE_RELEASE(data_property_definitions); >> >> >> >> fc_class->SetBaseClass(NULL); >> >> classes->Add(fc_class); >> >> >> >> printf(" -> Defining non feature class nfc \n"); >> >> >> >> FdoPtr<FdoClass> nfc_class = FdoClass::Create(L"nfc", L"nfc"); >> >> nfc_class->SetIsAbstract(false); >> >> >> >> data_property_definitions = nfc_class->GetProperties(); >> >> id_property_definitions = nfc_class->GetIdentityProperties(); >> >> >> >> data_property_definition = >> >> FdoDataPropertyDefinition::Create(L"IdProp", L"IdProp"); >> >> data_property_definition->SetDataType(FdoDataType_Int32); >> >> data_property_definition->SetNullable(false); >> >> data_property_definition->SetIsAutoGenerated(false); >> >> data_property_definitions->Add(data_property_definition); >> >> id_property_definitions->Add(data_property_definition); >> >> FDO_SAFE_RELEASE(data_property_definition); >> >> >> >> data_property_definition = >> >> FdoDataPropertyDefinition::Create(L"Prop1", L"Prop1"); >> >> data_property_definition->SetDataType(FdoDataType_Int32); >> >> data_property_definition->SetNullable(true); >> >> data_property_definition->SetIsAutoGenerated(false); >> >> data_property_definitions->Add(data_property_definition); >> >> FDO_SAFE_RELEASE(data_property_definition); >> >> FDO_SAFE_RELEASE(id_property_definitions); >> >> FDO_SAFE_RELEASE(data_property_definitions); >> >> >> >> nfc_class->SetBaseClass(NULL); >> >> classes->Add(nfc_class); >> >> >> >> schemas->Add(schema); >> >> >> >> printf(" -> Applying the schema \n"); >> >> apply_schema_cmd->SetFeatureSchema(schema); >> >> apply_schema_cmd->Execute(); >> >> >> >> >> >> >> >> From: [hidden email] >> [mailto:[hidden email]] On Behalf Of Haris Kurtagic >> Sent: June-10-09 3:28 PM >> To: FDO Internals Mail List >> Subject: RE: [fdo-internals] King Oracle Issue >> >> >> >> How did you applied schema ? You mention feature and non-feature class ? You >> applied Autodesk schema , metadata tables? >> >> >> >> In King.Oracle for Oracle Table to become available as FDO class the table >> has to be in sdo_geom_metadata . You did that ? >> >> Of 'course Oracle user you are using to connect has to see those tables >> etc... >> >> >> >> Haris >> >> >> >> From: [hidden email] >> [mailto:[hidden email]] On Behalf Of Thomas Knoell >> Sent: Wednesday, June 10, 2009 8:42 PM >> To: [hidden email] >> Subject: [fdo-internals] King Oracle Issue >> >> >> >> Hi, >> >> >> >> I am working on a FDO based application that should use the King Oracle >> Provider to connect to a data source on an Oracle 11g instance. The >> application currently connects fine to an empty data store (the data store >> does not contain any tables) and successfully applies a test schema that >> consists of a feature and a non feature class. The problem arises in the >> following step where a describe schema request is executed. In this case, >> the result is one schema named KingOra and no classes. I expected the test >> schema and its corresponding classes being reported. >> >> >> >> The application has | ||||||||||||||||