[fdo-users] Adding new featureclass from existing table

[Bhogi]

Hi,

Yes, I know about this, tryed it and indeed it works. But the database in use by 
FDO will always have all f_ tables. When these tables are present the provider 
unfortunately does no auto detection.

Thanks.


Orest Halustchak wrote:
> Hi,
> 
> For the SQL Server provider, the fdo metadata tables are optional. You could just create tables that have geometry or geography columns into a new empty SQL Server database and the provider will detect them as feature classes. Have you tried that?
> 
> Thanks,
> Orest.
> 
> -----Original Message-----
> From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of bhogi
> Sent: Thursday, October 15, 2009 6:47 AM
> To: fdo-users at lists.osgeo.org
> Subject: [fdo-users] Adding new featureclass from existing table
> 
> 
> Hi,
> 
> I'm adapting a few apps that export GIS data to SQL server 2008. The goal is
> to make exported data also available to FDO.
> 
> In the beginning I solved the problem of making database tables available to
> FDO by inserting class definitions etc. in f_ tables and adding classid and
> revisionnumber fields to the tables. Althou working this "hack" is not
> acceptable in the long run.
> 
> I want to do this the correct FDO way, but don't know how.
> 
> There are two approaches I was considering:
> 
> 1) Create a table first and make it an FDO featureclass later
> BUT If I create a new feature class intended for the already existing table,
> the fdo will make a new differently named table.
> I could change the values in f_ tables, but that's reverting to "hacking"
> again.
> 
> 2) Make an FDO featureclass and insert new features in corresponding table
> via SQL as I did before
> BUT classid and revisionnumber need to be set. If I set these values via SQL
> I see this as reverting to "hacking" again.
> 
> Is there a way to acomplish this?
> Have I overlooked something?
> Is the 2) way considered as a valid way to insert features in featureclass.
> What if the FDO internals will change regarding these fields...
> 
> Adding new features the FDO way is not an option, there's just too much code
> to adapt.
> 
> Thanks.
>