Hi Roxanne,

>I can understand your questioning my "Processed Tables", I didnt go this route the first time around with my 2.6 app. And yes, I will substitute a view or cursor wherever I can. But some of my tables are millions of records, and since I have no good primary keys this makes anything I join together time consuming.

This primary key issue keeps popping up. I'm not quite sure I understand the problem. What are problems you are having with creating surrogate primary keys for these tables? I personally add integer primary keys to all of my tables and have found it extremely valuable.

>My thought is to use views/cursors in place of the Report Tables at the end of the modules, keep my psuedo-tables from Preprocess, and perhaps dump out the original source data to help with disk space. With the transfer, Restock, and Preprocess modules run at night, the replication makes up for itself with user response because when a report is requested from the app, half the work is already done.
>
It's very difficult to help you here as it requires really understanding what you are doing with the data to appreciate the tradeoffs between database maintenance and processing speed.

>>The other advantage of views and cursors from stored procedures is it is usually pretty easy to determine where the data came from when people come questioning.
>>
>When I'm questioned is over the phone... and I need to answer in terms of where the data came from in relation to the unix boxes. :( And with Stored Procedures, dont I want to avoid them since I'll be upsizing to SQL Server once the Data Warehouse System is in place? I thought I learned somewhere Stored Procedures and Triggers would be lost in Upsize process? The way I've been designing the actual processing is with all methods, straight *.prg procedures, and these cool Event Objects from the Mere Mortal framework.
>
Yes, you would have to recode the stored procedures in Transact SQL, but as long as your stored procedures are relatively sime and don't use xBase gunk, you shouldn't have tto much trouble doing that. The other possible advantage to this, although I am getting out of my depth here, is that I believe SQL Server can support server side cursors, which means that all the query processing is done at the server and the cursor stays on the server and is not transmitted across the n/w. This may be advantageous considering the size of the tables you are working with. But as I said, I'm out of my depth so I'll shut up now :-).

Cool Event Objects??? Why haven't I been informed of this. What are they, where do I dind out more ?

Oh BTW about the textfile OBDC driver, I forgot to mention that is is read only! So it is only any use for importing data.