The code examples that are provided with beta 2 rely on Transact-SQL for all persistence. The TrackingStore database (23 tables) has 70 stored procedures. A maintenance nightmare.

I'm thinking about porting the TrackingStore to LLBLGen objects which will allow me to eliminate virtually all of the stores procedures. I think that this will lead to much more maintainable code.

Good idea or waste of time? Anyone interested in this?

Jeff

Jeff,

For my understanding, the TrackingStore database is a fundamental part of WF ?

regards, Danny

DvK wrote:

Jeff,

For my understanding, the TrackingStore database is a fundamental part of WF ?

regards, Danny

Thus far, I can't determine whether that's true or not. I find it hard to believe that a framework would "hard-code" stored procedure calls.

Jeff

Looking for it but failed to located it. Please can you help by supplying the URL?

Good idea or waste of time? Anyone interested in this?

BTW, I think its a brilient idea

sparmar2000 wrote:

Looking for it but failed to located it. Please can you help by supplying the URL?

http://www.windowsworkflow.net/default.aspx?tabindex=0&tabid=1

It appears that the stored procedure calls are hard-coded into the framework. No adapters, no nothing.

What a shame.

Jeff

What!?? Hardcoded? ieks!

Silly people, you simply need to make an LLBLPersist object using the base interfaces/classes. the SQLPersist class that comes with it is just an example and one that they will include, there is nothing that keeps you from writing your own persist engine.

The Portal people at MS have already created a DocPersist object that allows you to store the work flow in their document portal database as an example.

John

Thanks John, I already wondered how they (MS) could get away with this

jtgooding wrote:

Silly people, you simply need to make an LLBLPersist object using the base interfaces/classes. the SQLPersist class that comes with it is just an example and one that they will include, there is nothing that keeps you from writing your own persist engine.

The Portal people at MS have already created a DocPersist object that allows you to store the work flow in their document portal database as an example.

John

ok. Found this: http://www.manuelfoerster.net/wordpress/40/ and this: http://blogs.msdn.com/moustafa/archive/2006/03/02/542459.aspx

So this is beginning to make some sense. However, I can't even begin to account for the 70 stored procedures and the 23 tables in the TrackingStore database. Nevertheless, I stand corrected on my previous statement regarding "hard-coding".

Jeff