>Cursor adapters seem to be very flexible to me. For me, I like the idea of custom dataenvironments full of cursor adapters whereby the dataenvironments beforeOpenTables method has some dynamic code to 'point' the dataenvironment at the right database. But the names of the tables don't actually change in my scenario. I see the ability to switch out the data environment full of CA's pointing at free tables to one with CA's pointing at an SQL backend or something else as the big accomplishment.
>
>But CA's are totally programmable/buildable on the fly. Use a master class in combination with metadata of the tables so you would include in the init event of the CA code to look up the passed table reference from the metadata and 'populate' the CA object appropriately. Since you are specifically targeting free tables the code should be fairly straightforward; but somewhere the details of the tables has to be available to populate the single subclassed master CA with the specific table 'sql' update commands. Otherwise, you are back to opening the table to get the information in which case you've violated the reason for needing the CA in the first place.

Thanks a lot. In our case we decided to use the same table name and table statucture, but different directories. So, I guess, if we switch path prior to open the CA, the once build CA is going to work.

My colleague is going to try the whole scenario in the following days.