Attempts to simply set the SupportsSchemaModification to false resulted in other undesirable exceptions when dropping tables, though now that we have disabled 'drop table' support anyway this could be a temporary work around for others.<br>
<br>The evaluation of the feature class element state as noted for both addition and deletion would be a great addition. The noticed that the PostGIS provider for example provides a nice logical layout. <br><br>If we could call the applySchema once for each newly added table and in the provider only conditionally execute the existing create table code based on added elements, both added and dropped states are already set by the caller, then the current work around in our code could be discarded. The next step would be to implement dropping tables using the same state mechanism.<br>
<br clear="all">ryan<br><br><div class="gmail_quote">On Thu, Mar 24, 2011 at 1:49 AM, Haris Kurtagic <span dir="ltr"><<a href="mailto:haris@sl-king.com">haris@sl-king.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Ryan,<br>
<br>
Thank you for your emails and well described problems.<br>
<br>
I believe your approach is ok. I could quickly either set capability<br>
SupportsSchemaModification to false or I could check for "added flag"<br>
for classes in schema and create only those.<br>
It still wouldn't be full SupportsSchemaModification but could help at<br>
least with most common case of adding new table.<br>
<font color="#888888"><br>
Haris<br>
</font><div><div></div><div class="h5"><br>
On Wed, Mar 23, 2011 at 7:29 PM, Ryan Proulx <<a href="mailto:ryan.proulx@safe.com">ryan.proulx@safe.com</a>> wrote:<br>
> Perhaps this is not quite the right forum, but despite being successful<br>
> using the new SL-King SpatiaLite FDO Provider (version 0.1.2 as made<br>
> available here) to read from SpatiaLite databases we have encountered a few<br>
> issues writing to SpatiaLite.<br>
><br>
> One of the primary issues in using this provider is that we were unable to<br>
> write to more than one table to a schema. An SQL error is raised when<br>
> attempting to create the second table indicating that the first table<br>
> already exists. In this example creating two identical tables named 'states'<br>
> and 'states2' respectively the 'states' table is written correctly first and<br>
> then the following exception is thrown for the second time we apply schema<br>
> for the 'states2' table:<br>
><br>
> 'class FdoException exception: Error prepare statement 'CREATE TABLE states<br>
> ( AREA DOUBLE,POP1990 DOUBLE,POP2000 DOUBLE,POP90_SQMI DOUBLE,PRIMARYINDEX<br>
> INTEGER,STATE_ABBR TEXT,STATE_FIPS TEXT,STATE_NAME TEXT,SUB_REGION TEXT,<br>
> PRIMARY KEY ( PRIMARYINDEX ) ) ,! sqlite_error='table states already exists'<br>
><br>
> It appears that though the provider claims 'SupportsSchemaModification', all<br>
> features for a schema are expected to be provided at once as it attempts an<br>
> SQL create table statement for each table currently in the schema.<br>
> Thus, if a schema is built up and applied one table at a time, as we do in<br>
> our application, the above error results. Similarly there is no support for<br>
> dropping tables when they are removed from the schema.<br>
><br>
> Is this the wrong approach (it does seem to work nicely in other providers)?<br>
> Is this planned on being fixed soon?<br>
><br>
> For now we have coded around the creation issue but have had to disable<br>
> table dropping.<br>
><br>
> Thanks<br>
> ryan<br>
><br>
</div></div></blockquote></div><br>