Hi,

in our application framework we make frequent use of temporary tables, e.g., to pass data to Crystal Reports or things like this.

These use cases are well defined (not just ad-hoc), and for each of these temporary tables, we do have an actual (always empty) table in our schema (which defines the structure). So we can generate entities for those tables, which correspond exactly to the temporary tables we have at runtime.

What would be great is if we could populate an EntityCollection with the data of a temporary table at runtime, with the ability to save the EntityCollection back to the temp table.

Filling the EntityCollection is already possible with projections, but it is cumbersome since all fields have to be defined even though the whole structure of the temp table was generated into the entity already at design time..

In essence, all that's changed between between design time and runtime is the table name. So to me it seems all that's needed to make this possible is to change the PersitenceInfo of the entity in question so that it points to the temporary table.

Is there a way to accomplish this?

Thanks,

andreas

There's a way to change the target table at runtime But I need to know whether you are using the adaptor template set or the selfservicing template set But IMHO there is a better design approach if I may suggest. Since the temp tables have a fixed schema you can make use of the template table to store reports data with the help of an additional token field. so instead of creating and dropping tables you should insert and delete rows based on their token

Thanks for your quick answer.

We're using Adapter (still 3.1).

I do agree with your proposal; but that's not the kind of thing you change after several man-years worth of code was written.

Please check this thread (2 pages :>). Detailed solution is on the second page http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=7338

You will have to derive from the DataAccessAdapter and overwrite some methods (GetFieldPersistenceInfos) there you may use an additional property passed to the derived class which decides the temp table name to use, and have your logic to check on the current entity if you need to rename or change the SourceObjectName or not.

Thanks, that should work for us.

If I understand correctly, this solution won't allow a single DataAccessAdapter to handle several Temptables of the same Template Table (since there can be just one "renaming" target of the Template table). But that should not be too much of a problem.

Nope. you'll set the derived DataAccessAdapter's property to the temp table name. you can even set this in the CTor.