Problem Exporting one table.

[Royce]

I have a function I have used for years that exports the Table Schema to a .xsd file for saving in subversion source control. One table of 162 gives me error 31532 when I try to export it.

I can export it as a local table, and I can open the backend and export it there. I have relinked it. Did a compact and repair on both the front and back database. Did a Decompile, recompile, and still get the same error on the one table.

The problem table does have a Calculated field. Other than that it is standard.
The export line follows. td is a TableDef object, CleanFilesNames strips out all spaces and non alpha characters.

Application.ExportXML ObjectType:=acExportTable, DataSource:=td.Name, _
    SchemaTarget:=sExportLocation & "Table_" & CleanFileNames(td.Name) & ".xsd"

Does anybody know if ExportXML will work with calculated fields? Is there something else I should be checking?

 

[CJ_London]

Does anybody know if ExportXML will work with calculated fields?

Don't know - why don't you take a copy of the table, delete the calculated field and see if it then works?

 

[Royce]

Brain dead. Yea, it's the calculated field. (working too many hours.)

But what I meant to ask, Is there a workaround? (I've done a lot of searching and have not found anything that confirms the problem, or gives a work around. As this is one of the best forums around, I thought I'd try to get some expert comments.)

 

[gemma-the-husky]

well, rather than export the table, just make a query which excludes the problem field, and export the query.

make td a querydef object rather than a tabledef.

set qdf = currentdb.querydefs("myquery")


(another reason to not use access "improvements" )

 

[Royce]

I'm only exporting the schema, and the only reason for exporting it is to have a copy of changes in Subversion. Exporting a query does not solve that problem.

Right now the only solution seems to be to remove the calculated field and do the calculations in the form and report source queries, which is what I have always done in the past.

Seems weird to give up a feature, but I've found having a history of changes just to valuable to give up.

 

[CJ_London]

do the calculations in the form and report source queries, which is what I have always done in the past.

Makes you wonder what the benefit of a calculated field is. Tables should never be accessed directly by users, so you use a query and put the calc there

 

[gemma-the-husky]

you could just store a table of the field details, rather than write to xml. that way the dbs is self contained.

sort of

 for each tdf in tabeldefs
     for each fld in tdf.fields
         for each prp in fld.properties
             write details to a schema table
         next
     next
 next

if you are doing this, then you can document the indexes and even relationships the same way. Quite an instructive task.