Quote: >>5) Later this table can have any practical number of fields

of valid types (generally Char,VarChar,Int, Date, Double), but which

and how many fields depends on the users requirements

[snip]

12) The question is how to tackle this problem of base table fields

having changed?

Fox will not let you do this when you define a view as SELECT *

instead of naming field individually. When you define a view with

SELECT *, Fox grabs the current table structure, and sets its DBC

properties for the columns based on that structure. If the structure

changes, when Fox does a SELECT * on the new structure, there are now

columns that it doesn't know how to handle, and as a result will throw

the error you are seeing.

The only solution (short of a redesign of your data) would be to use a

temporary DBC, and create the view on the fly. This way, Fox will grab

the current structure to define the view. See the code in

cDistinctDynamicViewCursor for samples on how to do this.

Hi Ed

You guys have thought about everthing in this framework. Thanks a

lot.

Quote: >>(short of a redesign of your data)

Any suggestion for such a requirement.

Quote: >>The only solution would be to use a temporary DBC, and create

the view on the fly. This way, Fox will grab the current structure to

define the view. See the code in cDistinctDynamicViewCursor for

samples on how to do this.

Better still in the BO's DE I switched iDynamicViewCursor to

cDistinctDynamicViewCursor but that didn't do the job.

Is there a different way to use it?

Quote: >>Quote: >>(short of a redesign of your data)

Any suggestion for such a requirement.

When you have a variable column structure, it is best to redesign

things into an atribute-centric design. IOW, instead of adding or

removing columns, you add rows to a related attribute table, with the

"column" name as the key field. It's more work, especially in creating

SQL joins, but it is amazingly flexible.

Quote: >>Better still in the BO's DE I switched iDynamicViewCursor to

cDistinctDynamicViewCursor but that didn't do the job.

I didn't mean to use that class; it would only come into play when two

bizobjs try to use the same view. All I meant was you could grab some

of the DBC and view creation code from that class's code.

Quote: >>When you have a variable column structure, it is best to

redesign things into an atribute-centric design. IOW, instead of

adding or removing columns, you add rows to a related attribute table,

with the "column" name as the key field. It's more work, especially in

creating SQL joins, but it is amazingly flexible.

Any white paper regarding this, which I can go through, I am open to

ideas as this is the first app I will be trying it. I might as well

do the research. I had this kind of logic in FPD and was working well

but now the concepts have changed.

While we are at it, does this suggestion of your help in dynamically

creating computed fields? This is a major limitation in my idea as

when it comes to form creation I just create a form dynamically using

a lot of @ say gets (FPD).

Quote: >>I didn't mean to use that class; it would only come into play

when two bizobjs try to use the same view. All I meant was you could

grab some of the DBC and view creation code from that class's code.

Okay, though I studied it after posting and I found out that it is

looking for a if used condition. Anyway, where would you propose I

put in the converted code.

The structure will be modified outside the app, and the structures

won't change so frequently as in the start, once settled all will be

smooth.

Can I make it more oop than procedural, ie. a form to do a blank

conversion of all the FlexiTables. Hey I don't know what all

FlexiTables are there, I would like to avoid hard coding TableNames.

Thanks for you help.

Please advise.