While reviewing threads on the MSDN Training and Certification Forum, I read a reply from Nilkamal0007 in relation to a question on SQL Server 2012 certification. What caught my eye about this particular reply was that Nilkamal0007 provided links to exam content published in Microsoft’s exam catalogue; something I didn’t know had been published.  So what does this mean?  It means that the Beta cycle for these exams is close to going live.

I don’t know the exact release dates for the new SQL Server 2012 certifications (or when the beta period actually begins) however the exam catalogue does show the following:

Published: June 8, 2012 (In development)

70-466: Implementing Data Models and Reports with Microsoft SQL Server 2012

Published: June 11, 2012 (In development)

70-464: Developing a Microsoft SQL Server 2012 Database
70-465: Designing Database Solutions for SQL Server 2012

Published: June 12, 2012 (In development)

70-461: Querying Microsoft SQL Server
70-462: Administering a Microsoft SQL Server 2012 Database
70-463: Building Data Warehouses with Microsoft SQL Server 2012
70-467: Designing Business Intelligence Solutions with Microsoft SQL Server 2012 Platform

Looks like I better get my study cap on

The other day I was trying to import data from an Excel spreadsheet into a SQL Server table using OPENROWSET (something I’ve done numerous times before) but I just couldn’t get it to work on our development server (I could get it to work on my development machine though).  My code was quite simple:

INSERT INTO Cruise.Pricing
SELECT CruiseCode, Rate, Fare
FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0',
     'EXCEL 12.0;Database=d:\ozdata\PricingData.xlsx; 
     HDR=YES;IMEX=1','SELECT CruiseCode, Rate, Fare FROM [sheet1$]');

Yet SQL Server kept throwing the following error:

OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)" returned message "Unspecified error". 
Msg 7303, Level 16, State 1, Line 1 
Cannot initialize the data source object of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "(null)".

Now I really do love developing with Microsoft products but what the heck does “Unspecified Error” mean?  Come on! Really!  How difficult can it be to provided decent error messages.  Anyway, I digress.

Like any good developer, I launched Google and searched for the above error which resulted in a number of hits; The first of which was the article Microsoft.ACE.OLEDB.12.0″ for linked server “(null)” returned message “Unspecified error” (dated 11 September 2011) which was indeed related to my search however the solution was to open SSMS with Administrator rights (Hint #1).  Just as I was about to close the article, I saw the following comment posted by Yves Forget at the bottom (Hint #2):

Were fixed a similar problem on Windows 2003 server by allowing read/write access to the users executing the query to the temp directory of the user running SQL Server (on Win 2003, it would look like c:\Documents and settings\SQLDBA\Temp). This is because SQL Server copies the file to that directory before opening it (probably to ensure exclusive access to the file).

Not been able to do the same on Windows Server 2008, however.

I found the comment interesting however didn’t pay much attention to it as we’re running Windows Server 2008 and the comment stated this fix worked for 2003 but not 2008.

Over the next hour or so I read countless articles, most of which suggested to run the following commands in SQL Server (which despite already being run on the server, were run again):

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO

sp_configure 'Ad Hoc Distributed Queries', 1;
GO
RECONFIGURE;
GO

EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0'
	, N'AllowInProcess', 1
GO

EXEC master.dbo.sp_MSset_oledb_prop N'Microsoft.ACE.OLEDB.12.0'
	, N'DynamicParameters', 1
GO

Some even suggested that the TEMP directory permissions (discussed in the 1st article I read) can cause problems on x86 machines however I dismissed these comments as we are running x64 (Hint #3).  Besides, it works on my 64bit development machine.  Fed up with playing this game, I went to lunch.

BTW, some of you are probably already thinking “Why didn’t he just use SQL Server’s Import and Export Wizard?”. Well, the wizard uses SSIS and SSIS is a 32bit application which means that the 64bit Microsoft Office 12.0 Access Database Engine OLE DB Provider (a.k.a. Microsoft ACE OLE DB 12.0 Provider) is not available in the wizard (refer to my previous post on Consuming Microsoft Access or Microsoft Excel Data Sources in 64-bit Environments).  That’s why I couldn’t use the wizard.

Anyway, during my break I convinced myself that the only plausible explanation as to why I was experiencing these problems was that the provider must have become corrupt and all I needed to do was reinstall it.  Well, I was wrong.  I still got the same unhelpful error message.

(Insert long break here)

I bet you’ve already guessed what the problem was.  Yep, it was a permissions problem. 

During a tidy-up of the accounts on the development server, I had changed the SQL Server service to use a local account instead of my domain account (Yes I know).  This meant that when I executed the OPENROWSET statement in SSMS, it was executing under the context of my domain account which did not have write access to the TEMP directory of the SQL Server service account (BTW, the instance of SQL Server on my development machine was still running under my domain account.  That’s why it didn’t fail there i.e. The service account and the account SSMS was launched under were the same therefore the required permissions were already in place). 

I understand why SQL Server needs to use a temporary directory however I don’t understand why there’s a requirement to set permissions on the SQL Server service accounts TEMP directory manually. Surely there’s a better way to handle this requirement/limitation (and surely there’s a better error message other than “Unspecified Error”!)

- Sometimes you have to stop and smell the roses (or get smacked in the face with a cricket bat!)

Since writing this article I’ve discovered that the Int32 error discussed below occurs irrespective of whether the ServerPort value is greater than 32767 i.e. even a value of 21 (the default) causes the same error.

I’ve also discovered that the following additional FTP Task properties cause the same Int32 error (irrespective of their value):

• ChunkSize
• Retries
• Timeout

I believe this error occurs because the datatype for these properties is being stored in the configuration file as Int32 and the Integration Services Project Conversion Wizard expects them to be Int16.

There’s going to be a lot of unhappy people is this isn’t fixed in RTM!

Original Post

Stumbled across a couple of bugs the other day while upgrading a SSIS 2008 package to SSIS 2012 RC0.  The bugs relate to using a FTP Task with a Server Port greater than 32767.

The bugs identified have been reported via Microsoft Connect (item 721089) however I have been advised that fixes for these bugs won’t make it into the RTM version of SQL Server 2012.  Therefore, if you’re using FTP Tasks with a Server Port number greater than 32767, you are going to have problems converting your SSIS projects to SSIS 2012.

I apologise in advance for the length of this post however there are quite a few bugs and workarounds to cover.

The Problem

I have a SSIS project which contains a FTP Task configured using a configuration file.  One of the properties configured via the configuration file is the FTP Server Port which is set to 36360. 

When upgrading this project to SSIS 2012 (RC0) using the various conversion wizard (3 to be precise!), the conversion fails with the following error:

The parameter value could not be assigned because the data types did not match. The provided value was of type "Int32", the expected data type was "Int16".

Subsequent attempts to rectify the error can also result in the following exception loop:

An exception occurred while setting the parameter value for “ServerPort” (Int16). The exception message was: Value was wither too large or too small for an Int16.

and the following errors:

There were errors while loading the package. See the error list for details.

Error loading Package.dtsx: Failed to decrypt protected XML node "DTS:Property" with error 0x8009000B "Key not valid for use in specified state.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available.

FTP Server Port defaulting to 21

Steps to Reproduce Errors

Create Legacy SSIS Package

The following is an abridged version of creating a package containing a FTP Task.  Please refer to SQL Server Integration Services (SSIS) – Part 22 – Receive File using FTP Task in SSIS Package if you require further assistance with creating this package.

1. Create a SSIS 2008 project containing at least 1 SSIS package
2. Add a FTP Task to the package and configure it to use a Server Port of 36360  (You can use any value greater than 32767 (Int16 upper boundary).  I’m using 36360 as it’s easier to demonstrate).
3. Enable package configurations and add a XML Configuration File to the project. 
4. Add the ServerPort property of the FTP Connection Manager to the configuration file.
5. Save and close the project.

One thing you’ll notice while completing Step 4 is that the type of the ServerPort property is listed as Int16, despite the default value being 36360 (bug in SSIS 2008). There’s no way to change the associated type. 

If you view the configuration file created at Step 4, you’ll see that the ValueType of the ServerPort property is listed as Int32 despite the type being listed as Int16 in the Package Configuration Wizard.

BTW, changing the data type in the configuration file to Int32 does not change it to Int32 in the Package Configuration Wizard.  Changing this value also causes the property to disappear from the list of available properties to convert to package parameters during the Integration Services Project Conversion wizard steps (discussed below).

Convert Legacy SSIS Package to SSIS 2012 (RC0)

During this process you will encounter 3 conversion wizards (!!!) in the following order:

1. Visual Studio Conversion Wizard
2. SSIS Package Upgrade Wizard
3. Integration Services Project Conversion Wizard (a.k.a. Convert to Project Deployment Model)

The first wizard simply converts a legacy Project or Solution into 2012 RC0.  The second wizard converts SSIS packages to 2012 RC0.   The third wizard converts a project to use the new Project Deployment Model.

Visual Studio Conversion Wizard

1. Launch SQL Server Data Tools
2. Open the legacy project created above
3. Follow the Visual Studio Conversion Wizard steps (using the default values selected by the wizard) to complete the conversion of the Solution.

Nothing special to report here.

SSIS Package Upgrade Wizard

Prior to the completion of the Visual Studio Conversion Wizard,  the SSIS Package Upgrade Wizard launches (It’s essentially the last step of the Visual Studio Conversion Wizard).

1. Follow the steps of the SSIS Package Upgrade Wizard (using the default values selected by the wizard) until you get to the “Select Package Management Options” screen. 

   Note that there’s an option to “Ignore configurations”.  Checking this option seems to have no affect on the conversion process as the reported errors (which I now know relate to configuration file properties) still occur.

   

2. Click the “Next” button.
3. Click the “Finish” button to start the conversion process.  After a few seconds you’ll be advised that the conversion process failed. 
4. Click on the Messages hyperlink to view the conversion errors. The interesting thing is that one of the errors talks about decrypting a protected XML node however I am not using encryption and there is no mention of any data type errors.

   

5. Click the “X” at the top of the “View Report” dialog to close it.
6. Click the “Close” button to exit the SSIS Package Upgrade Wizard.
7. Click the “Close” button to exit the Visual Studio Conversion Wizard.

Integration Services Project Conversion Wizard (a.k.a Convert to Project Deployment Model)

If you look at Solution Explorer, you’ll see that your project has the words “Package Deployment Model” appended to its name.  This advises that your package is still using the legacy deployment method.

1. Right click on you project and select “Convert to Project Deployment Model”.  This will launch the Integration Services Project Conversion Wizard (Yes I know, confusing naming conventions).

   

2. Follow the wizard steps (using the default values selected by the wizard) until you reach the “Select Configurations” screen.  Ensure that the configuration file for your package has been loaded.  If it hasn’t loaded, click the “Add Configurations” button to add the relevant configuration file.

   

3. Clicking the “Next” button takes you to the “Create Parameters” screen where you can select what properties in your configuration file should be converted to Project/Package Parameters.  Ensure that ServerPort is selected and has a scope of Package.

   

4. Clicking on the “Next” button takes you to the “Configure Parameters” screen.  Note that there is no indication that the ServerPort parameter is invalid.

   

5. Click the “Next” button.
6. Click the “Convert” button to start the conversion process. After a couple of seconds a dialog box appears advising that the project has been converted to the “Project Deployment Model” however in the background you will see that the conversion actually failed (bug).

   

7. Click on the “Ok” button to close the dialog box
8. Click on the “Failed” hyperlink to view the error message.  Once again there is no real indication of what exactly caused this error (not hard to work this out as there is only one value that could cause this error in this project. Not so easy when you’re converting a large number of values though!).

    

9. Click the “Save Report” button to save the conversion report.
10. Click the “Close” button to close the wizard. 
11. Navigate to the location where you saved the conversion report and open it.  You will see that the report provides no information whatsoever on the error that occurred during the conversion process.  It doesn’t even state that the conversion failed.
12. Close the report.

You will see that your project still has the words “Package Deployment Model” appended to its name. Further confirmation that the conversion failed.

Investigating the Error

This is where things get a little messy as there are two paths that can be taken to identify and rectify the conversion error however both paths produce additional errors along the way.

Path 1 – Running the Convert to Project Deployment Model wizard again without modifying the SSIS Package

Please Note: Do not open the package in the SSIS designer (i.e. don’t double click on the package or select “View Designer” from the context menu when you right click on the package) before undertaking these steps.

1. Launch the “Convert to Project Deployment Model” wizard again and follow the wizard steps (using the default values selected by the wizard) until you reach the “Configure Parameters” screen.
2. Click on the text 36360 (i.e. click on the cell containing this text).  Now try and click on the ellipse button next to the ServerPort parameter, the Previous, Next or Cancel buttons, or the Hyperlinked wizard steps
   
3. You have now entered an exception loop (bug!) which displays the following error:

   

   The only way out of this loop is to click on the “X” at the top right of the wizard as the Cancel button can’t be clicked.
   

4. Click the “X” at the top of the wizard and confirm that you want to cancel the conversion process.
5. Launch the wizard again and follow the wizard steps (using the default values selected by the wizard) until you reach the “Configure Parameters” screen.  Do not click on the cell containing the 36360 value otherwise you’ll enter the exception loop again
6. Click on the ellipse button next to the ServerPort parameter to launch the “Set Parameter Details” dialog. Notice that the data type is set as int16 and there’s no way to change it.
7. Move your mouse over the red and white exclamation icon next to the Value property. A ToolTip is displayed advising that the value is either too large or too small for an Int16

   

8. Change the value to 21 and click on the “Ok” button.
9. Complete the rest of wizard.  This time the conversion should complete without error.

If you view the converted package in the designer (by double clicking on the package) and then view the Parameters tab, you will see a ServerPort parameter of data type Int16 and a value of 21.  Change the data type to Int32 and the value to 36360. Your package has now been successfully converted to SSIS 2012 RC0.

Path 2 – Running the Convert to Project Deployment Model wizard again after modifying the SSIS Package

This path requires you to use the original legacy SSIS package you created at Create Legacy SSIS Package above i.e. don’t use the converted project created in Path 1.

1. Follow all the steps in Convert Legacy SSIS Package to SSIS 2012 (RC0) above.  Move onto the next step once all the conversion wizard steps have completed.
2. Double click the SSIS package (in Solution Explorer) to open it in the designer.  You will get the following error:

   There were errors while loading the package.  See the error list for details.
   

3. Click on the “Ok” button to close the dialog and view the Error List.  There is one error:

   Error loading Package.dtsx: Failed to decrypt protected XML node "DTS:Property" with error 0x8009000B "Key not valid for use in specified state.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available.
   
   

   BTW, this package doesn’t use encryption so I suspect that this error actually relates to the Int16 conversion error (bug?).
   

4. Double click on the FTP Connection Manager to open the FTP Connection Manager Editor.  Notice that the ServerPort value is 36360.  There is no indication that this value is what caused the conversion error.
5. Close the FTP Connection Manager editor.
6. Click on the Parameters tab at the top of the designer.  Notice that no configuration properties were converted into package parameters. This indicates that the error received during the conversion process was probably caused by one of the properties in the configuration file as we told the conversion wizard to convert these properties into parameters and none have been converted..
7. Switch back to Control View by clicking on the Control View tab.
8. Double click on the FTP Connection Manager again to open the FTP Connection Manager Editor.  Notice that the ServerPort value has been changed to 21 (bug!).
9. Change the value back to 36360
10. Close the FTP Connection Manager Editor and then open it again.  Notice that the value has reverted back to 21 (bug!). 
11. Change the value back to 36360 and close the FTP Connection Manager Editor (Btw, the value has actually been reset back to 21 behind the scene at this point.  You just don’t know it at this stage) (bug!).
12. Save the package and project.
13. Launch the “Convert to Project Deployment Model” wizard again and follow the wizard steps (using the default values selected by the wizard) until you reach the “Configure Parameters” screen.  Notice that the ServerPort parameter value shows 21 despite it being set to 36360 (bug!). 

    

    Please note: If you try to complete the rest of the conversion process using the value of 21 without following the next couple of steps, you will still get the reported Int16 to Int32 error message despite the fact 21 is a valid Int16 value (bug!). 
    

14. Click on the Ellipse button of the ServerPort parameter.
15. Click on the “Ok” button of the “Set Parameter Details” dialog.  It appears that these two steps force the conversion wizard to convert the ServerPort property from a data type of Int32 to int16 despite no changes being made) (bug!).
16. Click the “Next” button.
17. Click the “Convert” button.  This time the conversion should complete without error.

If you view the converted packed in the package designer (by double clicking on the package) and then view the parameters tab, you will see a ServerPort parameter of data type Int16 and a value of 21. Change the data type to Int32 and the value to 36360. Your package has now been successfully converted to SSIS 2012 RC0.

Conclusion

Despite the fact that these errors shouldn’t occur in the first place, tracking down what caused the errors was a right pain in the butt as the error reports produced by the various conversion wizards and the error reported in the Error List while viewing the package were pretty useless.

As previously stated, the bugs identified have been reported via Microsoft Connect (item 721089) however I have been advised that fixes for these bugs won’t make it into the RTM version of SQL Server 2012.  Given the number of bugs discovered and the workarounds required to get past them, these issues should be fixed in RTM so please visit the connect item and vote for them to get fixed.

SQL Server 2012: AlwaysOn Availability Groups (SQL 142)

In this hands-on-lab you will learn take advantage of the new AlwaysOn features in SQL Server 2012. You will learn how to implement High-Availability and Data Recovery using SQL Server 2012 Availability Groups.

SQL Server 2012 – Working with Contained Databases (SQL 145)

In this lab, learn how to implement Contained Databases in SQL Server 2012.

SQL Server 2012 – What’s new in Manageability (SQL 147)

In this hands-on-lab you will learn about new manageability features in SQL Server 2012. You will learn how to take advantage of new features in SQL Server Management Tools, PowerShell, and features that will increase your productivity.

SQL Server 2012 – Installation and Configuration (SQL 149)

In this hands-on-lab you will build out a network environment that includes a Domain Controller, an multiple instances of SQL Server 2012.

SQL Server 2012 – Security and Compliance (SQL 150)

In this in hands-on-lab you will learn how to implement security and compliance in SQL Server 2012.

SQL Server 2012 – Upgrading to SQL Server 2012 (SQL 151)

In this hands-on-lab you will learn on how to upgrade to SQL Server 2012.You will learn how to use SQL Server Upgrade Advisor and Distributed Replay to upgrade a SQL Server 2005/2008 database to SQL Server 2012

SQL Server 2012 – What’s new in T-SQL (SQL 152)

In this hands-on-lab you will learn about the new T-SQL enhancements for SQL Server 2012.You will learn about new scalar functions, T-SQL constructs and how to take advantage of these new features.

SQL Server 2012 – Installing and managing SQL Server 2012 on Windows Server Core (SQL 153)

In this hands-on-lab you will learn how to deploy SQL Server on Windows Server core, and how configure connectivity and management of a Windows Server core based installation.

SQL Server 2012 – What’s new in Data warehousing and EIM

In this hands-on-lab you will learn about the enhancements in SQL Server 2012 for Data warehousing.

The wiki, which is based on the SQL Server 2012 Developer Training Kit, has been designed from a training perspective and organises content into an agenda like format (complete with presentations, demos and hands-on-labs) making it easy for individuals and organisations to develop their own SQL Server 2012 upgrade workshop.

Check it out today!

Sample Agenda

Day 1: Introduction and Database Engine Topics

Module 1: Introduction to SQL Server 2012

Day 2: Visual Studio, .NET and Business Intelligence Topics

Module 7: SQL Server 2012 Business Intelligence

PART I   Database Administration
 
2. High Availability and Disaster Recovery Enhancements
3. Scalability and Performance
4. Security Enhancements
 
PART II   Business Intelligence Development
 
6. Integration Services
7. Data Quality Services
8. Master Data Services

The complete free eBook (containing all 10 chapters) will be released in March 2012.

More information about this free eBook can be found at @MicrosoftPress and on the Microsoft Press blog

Larry Franks has put together a TechNet Wiki article on SQL Azure Connectivity Troubleshooting which covers:

1. Common Connectivity Errors
2. Verify SQL Server Management Studio Version
3. Verify Azure Firewall Settings and Service Availability
4. Verify That You Can Reach the Server IP
5. Isolating Network Problems

Given the uptake of SQL Azure, it won’t be long before the forums are flooded with requests for assistance so bookmark this link today.

UPDATE: If you’re looking for help with troubleshooting SQL Server connection issues, have a read of this.

Rick’s article covers both basic and complex connection issues and provides concise steps required to:

1. Gather Information about an Instance of SQL Server
2. Enable Protocols
3. Test TCP/IP Connectivity
4. Test Local Connection
5. Open a Port in the Firewall
6.Test the Connection

If you haven’t already bookmarked this article, do so today

UPDATE: If you’re looking for help on troubleshooting SQL Azure connection issues, have a read of this.

The concept behind the MVA is similar to that of a “Virtual University”; students select a course(s) to study and then do a self-assessment exam to gauge how well they’ve understood the study material. Students also accrue points for material studied and courses completed which are used to promote them through a recognition system (Bronze, Silver, Gold or Platinum Level) and provide them with a comparison on how they rank against other students in their country and around the world.

As it currently stands, there is only 1 SQL Server related course (Introduction To SQL Azure) currently available in Australia (and the United States and United Kingdom) however I have been advised by the Dean that new material will become available in the near future. I also mentioned earlier that there is additional content (SQL 2008/R2/Azure, .Net, Sharepoint, Silverlight, Windows Phone) available in other countries (mainly Spain and Colombia) with some of this content being in English and some in the native language of the selected country (the Microsoft study links are good as all you need to do is change the language setting of the site to a language of your choice and the content is translated. You can also use Google Translate on some of the content).

More information about the MVA can be found in the FAQ.

• Exam 70-453 – Upgrade: Transition Your MCITP SQL Server 2005 DBA to MCITP SQL Server 2008
• Exam 70-454 – Upgrade: Transition Your MCITP SQL Server 2005 DBD to MCITP SQL Server 2008 DBD
• Exam 70-455 – Upgrade: Transition Your MCITP SQL Server 2005 BI Developer to MCITP SQL Server 2008 BI Developer

This is in addition to exams that were retired on 30 June 2011

• Exam 70-431 – TS: Microsoft SQL Server 2005 – Implementation and Maintenance
• Exam 70-441 – PRO: Designing Database Solutions by Using Microsoft SQL Server 2005
• Exam 70-442 – PRO: Designing and Optimizing Data Access by Using Microsoft SQL Server 2005
• Exam 70-443 – PRO: Designing a Database Server Infrastructure by Using Microsoft SQL Server 2005
• Exam 70-444 – PRO: Optimizing and Maintaining a Database Administration Solution by Using Microsoft SQL Server 2005
• Exam 70-445 – TS: Microsoft SQL Server 2005, Business Intelligence ‒ Development and Maintenance
• Exam 70-446 – PRO: Designing a Business Intelligence Solution by Using Microsoft SQL Server 2005
• Exam 70-447 – UPGRADE: MCDBA Skills to MCITP Database Administrator by Using Microsoft SQL Server 2005
   

  Although these exams have, or will be, retired, the certifications relating to these exams are still relevant and will not disappear from your Microsoft Transcript. 

See Discontinued Exams for further information.