Yesterday, we attempted to move a few DNN installations from using a local SQL Server 2000 database to our new SQL Server 2005 server. First, we have a few non-DNN sites that are from pre-DNN days and are using the SQLOLEDB provider. After moving the largest database of 3.5 Gb, testing the site showed remarkable improvements of speed and performance. On pages with heavy data interaction, some loaded almost twice as fast. We then moved a few of the databases for smaller DNN sites to the new server. These sites were really small and a huge difference in speed could not really be determined without some page execution code being added. Then we tried moving a 2.5 Gb DNN database. The move went smooth, but the speed was horrible!

So, this had me thinking about incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect error again. Could an issue with the default provider for DNN and SQL Server 2005 be causing trouble? Oddly enough, when monitoring the remote SQL server, there was a huge spike on all 4 processors while processing the page. Well, I am going to find out tonight. I am going to test speed from a remote SQL Server 2000 server and see if there is any difference in speed. I'll post my results here...

UPDATE:

What a surprise. Checkout the results...

So, it looks like this is a 64 Bit and default DNN data provider issue. As I mentioned above, the old non-DNN sites using SQLOLEDB for the provider were super fast.

Could this be related: You may experience slow performance when you run 32-bit SQL Server tools on 64-bit operating systems

Look like a call to MS Support is in order. I just need to do a little more reseach on the DNN data provider. More details coming soon....

Update 1/4/2005:

After looking through the DNN documentation, I found the following: DotNetNuke Data Access.pdf (428.91 KB)