Essentially their users manage the data in SAP as well as the client stuff found in another database all together with their clients having Web based access to their own data.
So, we discovered a number of important things along the way.
+ SAP will not work if the SAP database resides in SQL 2008. At least the version we were working with which was very recent. ODBC errors happened when trying to connect. When we nuked SQL 2008 and put 2005 on the server and attached the databases in SQL 2005 SAP was happy.
+ The .NET application had some internal structures that refused to run due to the SQL 2008 version. SQL 2005 fixed those errors too.
We placed a copy of the original databases in the appropriate directories before attaching them in SQL 2008. So, after switching to SQL 2005 we were no further behind.
By the way, SQL 2005 would not allow us to attach the databases that were touched by SQL 2008. We always try and work with copies of the original data for situations just like this.
When it came to getting the .NET app, resident on another server, to communicate with SQL, the following port exclusions in the SQL server's Windows Firewall with Advanced Security were needed:
+ The port the SQL instance was on (default is 1433).
+ The SQL Browser port at UDP 1434.
Once we had things straightened out with the SQL version, ports needed, and the user permissions setup within the databases we were good to go.
All servers were running Server 2008 Standard x64 SP2.
Sent from my SBS Integrated Windows Mobile® phone.
ExchangeDefender Message Security provided by MPECS Inc: Click below to verify authenticity