I did not realise it was as simple as changing "CREATE TABLE (" to "CREATE table (compress=char, " into my CommandText. On my test table, what was 312Mb is now 12 Mb (262,144 rows with 3 string fields). Very impressive size reduction, and it writes20%  faster too. ... View more

Sorry keV as you mentioned several issues I was focussed on you 32-bit 64-bit issue. That is more common and the approach is to have all components on the same bitness. That is what my link was for. Rereading your question, I have more questions as answers. You are building something in .Net as Eguide AMO are also .Net applications you are building some functionality of that in the same way. The behavior on IOM and COM will be similar. I know those tools better. Builing in ADO .Net never needed to do. I know around Andreas it is/was done.  The "com" option is used for a local SAS dataset. It will start a SAS process for that, you should be able to see that running. In your .Net coding you will see CreateWorkspaceByServer   RemoveWorkspace that must be the one doing that. As starting a sas-process will take a lot of time (many seconds) starting and stopping this will cost a lot of time. When the sas-process  or the datasets behind is badly tuned you will have a bad performance. As far I can see you can submit SAS language code using Ado.                (SAS(R) 9.3 Integration Technologies: Windows Client Developer's Guide Using Local SAS with ADO - sample ) When you go for an IOM server. Also a SASs process need to run. I am recognizing the pooling and normal workspace servers as started by a object spawner (service). The normal workspace server is normally run (at OS level Unix) by a personal key and needing that password/login being propagated. The start time of that process needed to add for a response. The pooledworkspace server will run by a shared account (like the STP) and by that sharing you will not see the start process overhead.    ... View more