Microsoft Assessment and Planning (MAP) is a powerful tool to inventorize, assess and report your IT asset inventory. The new version, MAP 5.5 has new features that automates discovery of heterogeneous database instances for migration to SQL Server. The tool provides network inventory reporting for MySQL, Oracle and Sybase instances in your environment. Once you discover those instance, you can use SSMA to migrate.

Learn more about MAP Toolkit here and request for MAP Toolking 5.5 Beta participation from here.

The next version of the Microsoft Assessment and Planning (MAP) Toolkit—version 5.5— is now available for free download.

·         Download MAP 5.5

Simplify planning for migration to the latest Microsoft products and technologies with the Microsoft Assessment and Planning (MAP) Toolkit 5.5. This multifaceted tool is now even better—with assessment for easier migration to the Windows Azure platform, heterogeneous database discovery (of MySQL, Oracle and Sybase instances) for SQL Server migration projects, Windows Internet Explorer migration assessment, and much more—MAP 5.5 includes new features to help you streamline planning for your next migration project.

MAP works with the Microsoft Deployment Toolkit and Security Compliance Manager to help you plan, securely deploy, and manage new Microsoft technologies—easier, faster, and at less cost. Learn more.

Next steps:

·         Download MAP 5.5

·         Learn more about the MAP Toolkit.

·         View the MAP 5.5 demo.

·         Send your questions or comments to the MAP Team.

Get the latest tips from Microsoft Solution Accelerators—in 140 characters or less! Follow on Twitter: @MSSolutionAccel.

This video provides a quick overview of planning your database migration and setting up your SSMA, including connecting to your databases and configuring SSMA project setting.

Check out the other videos in this series:

• Introduction to SSMA
• Planning Your Database Migration
• Analyzing Database Using SSMA
• Converting Schema to SQL Server
• Migrating Data Using SSMA
• Automating Database Migration Using SSMA Console Application

One of the first decisions you need to make when migrating to SQL Server is to decide whether to migrate to a schema or to a database. There may be different concept of schema between your source database product and SQL Server. Unlike Oracle, for example, schema in SQL Server is not necessarily linked to a specific user or a login. SQL Server can also contain multiple databases. For more information about user schema concept in SQL Server, visit http://msdn.microsoft.com/en-us/library/ms190387.aspx

Using SSMA, you have the option to migrate a schema to a SQL Server database or migrate to a schema in a specified SQL server database.

• Migrate schema to a separate SQL Server Database

This is the default conversion approach in SSMA and is the preferred approach when there are few references between source database schemas. The converted schema will be assigned to "dbo" schema in SQL Server - the default database owner in SQL Server.

• Migrate schema to a SQL Server Database.

You can modify the project setting to map the source schema to a schema with the same name in an existing SQL Server database. You should consider to use this approach if your source schemas are deeply linked with each other (such as the case where you have many foreign key relationship to another table in a different schema). SQL Server does not allow constraint relationship to another table in a different database. You may implement a workaround using database triggers for one-off scenario.

To specify the conversion option, go to SSMA project setting > conversion > general:

Under default schema mapping, you can select whether to map "Schema to Database" or "Schema to Schema".

SSMA provides a project setting that allow you to customize how the conversion is done. This post describes the project setting options available for you as well as scenarios where you want to customize the setting.

SSMA project setting options are categorized into the following:

• Project Information:  provides project name and location where the project file is saved.

• General : provides more granular setting for the following:
  • Conversion: settings for schema conversion

There are many options for schema conversion, to simplify the selection, you can select "setting mode" that include predefined selection of the project setting. SSMA comes with three setting mode: default, optimistic and full. Optimistic mode contains the setting which leverages  native SQL Server syntax as much as possible but there is a chance that in some cases those syntax may not give the same results in SQL Server.  For example, in Optimistic mode, Oracle's substr() function is converted to SQL Server's substring() function. However, there are situation where substring() gives a different result:

• Oracle: SELECT substr('SQL Server', 5) FROM dual; -- returns 'Server')

SQL Server: SELECT substring('SQL Server', 5); -- returns error 'The substring function requires 3 argument'

• Oracle: SELECT substr('SQL Server',-6,3) FROM dual; -- return 'Ser'

SQL Server: SELECT substring('SQL Server',-6,3); -- return ''

If you select full mode, the substring is converted to SSMA's custom emulation function to give closer result to Oracle's function. Default mode selects the common option for most migration projects.

• Migration: settings for migrating data, including option to select whether migration is done through the client machine where SSMA is installed or through server side data migration engine" where data flows directly from source to target SQL Server. Other setting options include:

• Batch size : Batch size that is used during data migration. A transaction is logged after each batch.The default value is 1000.
• Break on error : Stops all data migration if any migration error occurs.

• Break on table error : Stops data migration of the current table if a data migration error occurs. SSMA will continue with the next table.

• Check constraints: Specifies whether SSMA should check constraints when it inserts data into SQL Server tables.

• Fire triggers: Specifies whether SSMA should fire insertion triggers when it inserts data into SQL Server tables.

• Keep identity : Specifies whether SSMA will preserve identity values when it inserts data into SQL Server. If this value is false, SQL Server will assign identity values.

• Keep nulls : Specifies whether SSMA will preserve null values in the source data when it inserts data into SQL Server, regardless of the default values that are specified in SQL Server.

• Table lock : Specifies whether SSMA will lock tables when it inserts data into the table during data migration. If the value is false, SSMA will use row locks.

• Loading system objects: setting to specify what Oracle object to be automatically loaded when connecting to Oracle.

Converting system objects consumes system resources and takes time. To improve performance, SSMA selects only the most frequently used system objects, as shown in the following list:

• SYS.DBMS_OUTPUT

• SYS.DBMS_PIPE
• SYS.DBMS_UTILITY

• SYS.STANDARD

• SYS.UTL_FILE

• SYS.DBMS_LOB

• SYS.DBMS_SQL
• SYS.DBMS_SESSION

If your Oracle objects refer to additional system objects, you should select those objects. If you do not select the system objects that are referenced by your Oracle database objects, SSMA will report conversion errors. If you receive conversion errors caused by missing system objects, select the missing objects in this dialog box. You can then repeat the conversion as necessary.

• Synchronization :  customize how SSMA loads and refreshes database objects, such as tables and stored procedures, into SQL Server.
• GUI: configures how data appears on the Data tab and if to include data reports with assessment reports
• Type Mapping: customizes how SSMA converts Oracle data types into SQL Server data types. SSMA provides flexibility for mapping data types. You can set different mapping for data type from table column, local variable, and/or argument.

[Updated 2/7/2012 Jiafei Yuan - Microsoft SQL Server Migration Assistant (SSMA) for Sybase v5.2.  The information provided below is still valid for SSMA for Sybase v5.2.  Users should download the lastest SSMA for Sybase]

This blog post explores the similarities and differences between Sybase Adaptive Server Enterprise (ASE) database applications and administration with Microsoft SQL Server to help you in your planning effort for migrating to SQL Server. The free Microsoft SQL Server Migration Assistant (SSMA) for Sybase v5.0 [Updated:  Please obtain the lastest SSMA for Sybase] provides a set of tools to help in your Sybase migration effort. In addition to the database migration tool, there is a free SQL Server Migration Assistant 2008 for Sybase PowerBuilder Applications v1.0 tool that reduces the effort, cost, and risk of migrating PowerBuilder applications to use SQL Server. You will also want to download and review the white paper “Guide to Migrating from Sybase ASE to SQL Server 2008” for a full understanding of how SSMA handles the migration of your Sybase database to SQL Server.

Overview of Similarities between Sybase ASE and SQL Server 2008 R2

Microsoft SQL Server was spawned originally from the Sybase code base. Since then, Microsoft has rewritten the engine and it no longer contains any of the original Sybase code. There are still similarities because the SQL language itself was born from Transact-SQL. In addition, many of the stored procedures interfaces used to manage the database remained the same to ease DBAs through the initial migration.

Similarities in the Database

Like SQL Server, Sybase uses a Database as a container for the database objects specific to an application on a Sybase ASE server. Database objects include: tables, rules, defaults, stored procedures, triggers, views, referential integrity and check constrains, functions, computed columns, and partition conditions.

Sybase ASE includes system databases like master and model that perform similar roles in SQL Server. SQL Server DBAs will recognize some of the similarities in the system catalog tables with Sybase ASE. Sybase ASE and SQL Server also share similar Database Consistency Checker (dbcc) commands.

The Sybase ASE security model is also similar to SQL Server. Logins control access to the server. Users control access to a specific database. Sybase ASE has the concept of a Role that is similar to the roles in SQL Server.

Sybase ASE uses Monitoring and Diagnostic (MDA) tables that are similar to SQL Server’s Dynamic Management Views (DMV) for monitoring and troubleshooting.

Similarities in the Tools

There is a summary of how some of the Sybase ASE tools match up to SQL Server.

• ISQL– Interactive SQL Parser. Similar to SQLCMD for command line execution of Transact SQL statements. SQL Server Management Studio provides a rich development, debugging and management experience for SQL Server.
• BCP– Bulk Copy Utility. Very similar to BCP with SQL Server. SQL Server Integration Services (SSIS) provides a comprehensive set of tools for moving data.
• Job Scheduler. Similar to SQL Server Agent for defining and scheduling database administration and maintenance tasks.
• Sybase WorkSpace 2.0. Similar to SQL Server Management Studio for developing, tuning, and debugging queries.

Similarities in Connectivity

Both Sybase ASE and SQL Server use an application layer request/response protocol called Tabular Data Street (TDS) for communicating between server and clients. The protocol is not compatible between the two server products, but is the basis for how data providers like ODBC, OLE DB, JDBC, and ADO.NET talk to both servers. For Sybase applications that use ODBC, OLE DB, JDBC or ADO.NET, the job of remediating the application is easier because of the availability of data providers for both servers. Often the process is as simple as changing the connection string attributes to point to SQL Server for Windows based applications. More information regarding how to remediate your application connectivity APIs can be found in the white paper Guide to Migrating Sybase Application Interfaces to SQL Server 2008.

For Sybase ASE applications that use the CT-Library, you want to consider mapping CT-Library calls to ODBC. The Guide to Migrating from Sybase ASE to SQL Server 2008 white paper provides guidance on how to remediate your application without having to do a complete rewrite.

Overview of Differences between Sybase ASE and SQL Server 2008 R2

SSMA provides help in migrating a vast majority of Sybase ASE objects and Transact-SQL code with a minimal amount of manual intervention. In order to support the migration effort, SSMA provides an extension pack that must be installed on the target SQL Server database instance. Instructions for installing the support pack can be found on the Microsoft SQL Server Migration Assistant (SSMA) for Sybase v5.0 [Updated:  Please obtain the lastest SSMA for Sybase] download page.

Here are some of the differences that you should be aware of that are detailed in the Guide to Migrating from Sybase ASE to SQL Server 2008 white paper.

Unsupported Sybase ASE System Functions

Many of the system functions in Sybase ASE have equivalent functions in SQL Server. SSMA can also emulate non-equivalent functions as user-defined functions installed into the sysdb database as part of the SSMA extension pack. The following list of system functions cannot be easily emulated in SQL Server because of physical organization and security model differences:

curunreservedpgs, data_pgs, derived_stat, get_appcontext*, host_id, is_sec_service_on, lct_admin, license_enabled, list_appcontext*, lockscheme, mut_excl_roles, proc_role, ptn_data_pgs, reserved_pgs, rm_appcontext*, role_contain, role_id, role_name, set_appcontext*, show_role, show_sec_services, syb_quit, syb_sendmsg, tempdb_id, used_pgs, valid_name, valid_user, rowcnt, tsequal

* This application context feature can be implemented by using temporary tables, but this is not recommended due to security issues.

Sybase ASE Transact-SQL Command Differences

The following table represents Sybase ASE Transact-SQL statements that are different than SQL Server 2008 R2. The table shows the level of support for migrating the command to SQL Server. In cases where there is partial or no support, please refer to the  Guide to Migrating from Sybase ASE to SQL Server 2008 white paper for suggestions on how to work around the problem. For cases where SSMA has partial or no support, the SSMA error report indicates the estimated time to fix the issue to help in planning your migration effort.

Dealing with Case Sensitive Databases

Sybase identifiers and object names are case sensitive. If you transfer the source to a case-insensitive target, name conflicts may arise. SSMA for Sybase v5.0 fully supports migrating a case sensitive Sybase database to a case sensitive SQL Server database. Here is a summary of what you will need to consider based on your target SQL Server configuration.

• Sybase case sensitive database migrated to a SQL Server case sensitive database on a case insensitive server (system catalog files are case insensitive). SSMA provides partial support. Variables differing only in case inside of stored procedures need to be updated manually. Other objects like table names and column names that differ in case are correctly handled by SSMA.
• Sybase case sensitive database migrated to a SQL Server case insensitive database. SSMA does not provide support. The expectation is that the target database should be setup to match in case sensitivity. If you are forced to migrate to a case insensitive server, object names and variables differing in case need to be updated manually to make them unique. One technique you could use is to script an entire database into a single file and then use a text editor to find and replace ambiguous names.

Wrap Up

Database Administrators and Database Developers should find plenty in common between Sybase ASE and SQL Server 2008 R2. The free Microsoft SQL Server Migration Assistant (SSMA) for Sybase v5.0 [Updated:  Please obtain the lastest SSMA for Sybase] can help you in migrating your Sybase ASE database and data to SQL Server 2008 R2. For more migration resources, please check out http://www.microsoft.com/sqlserver/en/us/product-info/migration-tool.aspx#Sybase.

If you are interested in migrating a Sybase ASA based application to SQL Server, please check out the white paper Guide to Migrating from Sybase ASA to SQL Server 2008.

SSMA automates conversion of most statement. There are a few features and syntax which SSMA is unable to migrate. In such situation, SSMA issues a migration error and for each error, SSMA provides estimated manual conversion time. I often asked how do we come up with the time.

Those manual estimation time was calculated based on the actual average time it takes by our developer team to fix the issue (exclude testing time). The manual estimation is intended to help you further quantify the complexity of the issue to help planning the database migration.

However, you should be aware of the assumption and limitation of the manual conversion time estimate:

1. The estimated manual conversion time was calculated based on the time it takes to resolve the issue using a specific approach. Often, there are more than one approach to resolve the issue. The actual hours to complete the migration and resolving the issue depends on the approach taken. For example when encountering Oracle User Defined Type (UDT), SSMA raised an error and the estimate was calculated based on the assumption that the UDT is converted to SQL Server TVP (as described in this article). However, you could also develop custom CLR type and convert the TVP to the CLR type -- in which case the actual conversion time will be vastly different.
2. Every migration error is assumed to be independent and the total estimated manual conversion time sums the estimate from individual errors. This may not be the case. You may have the same errors across multiple objects, in which once you resolve one error, you could copy and paste the solution to another object which would reduce the resolution time. Another example, you may have one underlying issue manifested in multiple errors. Consider the example in the screenshot above where SSMA is not able to convert INTERVAL data type. This results in the error for the function return type (line 6 on original Oracle source code) and expression to calculate the value (line 10 on the original Oracle source code). The two issues are dependent each other and the return type depends on converted expression.

In addition, the manual estimate hours depends on the skills of resources performing the migration. In order to resolve the issue, you will need to understand the original Oracle source and understand how best to redesign the statement in SQL Server. Thus, you need resource with knowledge of both Oracle and SQL Server. If you do not have resource with knowledge in both technologies, then you need to have separate resources (Oracle DBA and SQL Server developer) collaborating to resolve the issue. In this case, you need to factor the number of resources to your project planning.

I often find customers use the estimated manual conversion time as a comparative number to rank complexity between one schema/database to another.

The manual conversion time can still be useful for rough order of magnitude (ROM) estimation, but for more accurate project costing and time estimate, it is best to have the actual person(s) performing the migration to review the error list carefully, consider the consider the design approach and skill level, then refine the estimate accordingly.

Automating Database Migration to SQL Server 2012

The new version of SSMA - SSMA 5.2 provides the following major enhancements:

• Support conversion of Oracle %ROWTYPE parameters with NULL default
• Support conversion of Sybase’s Rollback Trigger
• Better user credential security to support Microsoft Access Linked Tables

Download SQL Server Migration Assistant (SSMA) v.5.2

Launch the download of the SSMA for Oracle.

Launch the download of the SSMA for Sybase.

Launch the download of the SSMA for MySQL.

Launch the download of the SSMA for Access.

SSMA simplifies database migration process from Oracle/Sybase/MySQL and Microsoft Access to SQL Server and SQL Azure. SSMA automates all aspects of migration including migration assessment analysis, schema and SQL statement conversion, data migration as well as migration testing to reduce cost and reduce risk of your database migration project. 

The new version of SSMA - SSMA 5.3 provides the following major enhancements:

• Support of Migration to MS SQL Server 2014.
• Improved conversion mechanism when migrating to Azure.
• New features in the Migration GUI.
• No requirement to get a License key to start using SSMA.

Download SQL Server Migration Assistant (SSMA) v.5.3 :

Launch the download of the SSMA for Oracle.

Launch the download of the SSMA for Sybase.

Launch the download of the SSMA for MySQL.

Launch the download of the SSMA for Access.

The SSMA product team is available to answer your questions and provide limited technical support. Contact the team at ssmahelp@microsoft.com

SSMA simplifies database migration process from Oracle/Sybase/MySQL and Microsoft Access to SQL Server and SQL Azure. SSMA automates all aspects of migration including migration assessment analysis, schema and SQL statement conversion, data migration as well as migration testing to reduce cost and reduce risk of your database migration project. 

The new version of  SSMA, Version  6.0 provides the following major enhancements:

• Materialized View support for Oracle

• Memory Optimized tables for Oracle
• Improved Azure SQL DB code conversion
• Extension pack functionality moved to schema to support Azure SQL DB
• Performance improvements tested for databases with over 10k objects
• UI improvements for dealing with large number of objects
• Highlighting of “well known” LOB schemas (so they can be ignored in conversion)
• Conversion speed improvements
• Show object counts in UI
• Report size reduction by more than 25%
• Improved error messages for unparsed constructs.

 Download SQL Server Migration Assistant (SSMA) v.6.0

SSMA for Access:  http://www.microsoft.com/en-us/download/details.aspx?id=43690

SSMA for MySQL: http://www.microsoft.com/en-us/download/details.aspx?id=43688

SSMA for Oracle:  http://www.microsoft.com/en-us/download/details.aspx?id=43689

SSMA for Sybase: http://www.microsoft.com/en-us/download/details.aspx?id=43691

On the closing note , Yes ! We've heard several of your valuable feedbacks / inputs. Thank you... and we're rolling out with the SSMA for DB2 very soon. Watch out this space for more information.

The SSMA product team is available to answer your questions and provide technical support related to SSMA. Contact the team at ssmahelp@microsoft.com

Microsoft Access stores all the connection strings for the respective linked tables in a system table called MSysObjects.  As seen below, the connection strings contain clear-text used id and password.  With the release for SSMA for Access 5.2, when creating link tables during migration, users will now have the option to not store the user id and password for the linked tables.

A new setting for linked tables can be found under the Project Settings menu.    By default, the Store user credentials setting is set to false, thus user id and password will not be persisted in the connection string of a linked table.  Switching the setting to true would provide the option to store the user id and password in the connection strings during the creation of linked tables.

It is important to note that after securing the connection string, MS Access users will have to enter the required user id and password whenever the linked tables are referenced in the MS Access Database application.  Below shows the prompt presented by MS Access.

The %ROWTYPE attribute in Oracle defines the particular record type of a row in a table.   A common usage of %ROWTYPE attribute is to have variables declared as ROWTYPE of a table to transfer data in and out of a procedure or function.  An IN ROWTYPE parameter of a function or procedure can be set with a default value.  Often, the IN ROWTYPE parameter is defaulted to NULL.  For example,

PROCEDURE proc_foo_rowtype( 
 row_a employees%ROWTYPE DEFAULT NULL ) 
 IS 
BEGIN 
 DBMS_OUTPUT.PUT_LINE('ID = ' || NVL(TO_CHAR(row_a.employeeID), 'NULL')); 
 DBMS_OUTPUT.PUT_LINE('NAME = ' || NVL(TO_CHAR(row_a.firstName), 'NULL')); 
END proc_foo_rowtype; 
 

PROCEDURE dbo.PROC_FOO_ROWTYPE 
 @row_a$EMPLOYEEID float(53) = NULL, 
 @row_a$FIRSTNAME nvarchar(max) = NULL 
AS 
BEGIN 
 PRINT 'ID = ' + isnull(CAST(@row_a$EMPLOYEEID AS varchar(max)), 'NULL') 
 PRINT 'NAME = ' + isnull(CAST(@row_a$FIRSTNAME AS varchar(max)), 'NULL') 
END 

Now, let’s have a little fun by having a ROWTYPE parameter in a nested procedure.  Here’s an example:

PROCEDURE PROC_FOO_OUTER 
IS 
empRow employees%ROWTYPE; 

 procedure proc_foo_inner( 
 row_a IN employees%ROWTYPE default null) 
 IS 
 
 BEGIN 
 DBMS_OUTPUT.PUT_LINE(‘First name = ' || NVL(TO_CHAR(row_a.FirstName), 'NULL')); 
 DBMS_OUTPUT.PUT_LINE(‘Last Name = ' || NVL(TO_CHAR(row_a.LastName), 'NULL')); 
 END proc_foo_inner; 

BEGIN 
 empRow.LastName := 'Smith'; 
 empRow.FirstName := 'John'; 
 proc_foo_inner(); 
 proc_foo_inner(empRow); 

END PROC_FOO_OUTER;                          

This example is quite straightforward.    Let’s assume there is an employee table with FirstName and LastName columns of nvarchar2(20) and nvarchar2(40) respectively.   The executing this procedure in Oracle would the following result:

 Now, let’s convert this procedure to SQL Server 2012 using SSMA for Oracle.  We will set the following settings in SSMA as such

• ·         local modules conversion is set to Inline
• ·         convert record as a list of separated variables set to Yes

The first setting is to convert the inner procedure into nested block Begin..End.  The second setting will create separate variables for FirstName and LastName.

Below is the result of the conversion.  There are two nested blocks corresponding to the respective inner procedures.  Each nested block contains its own variables for LastName and FirstName.   For the block representing proc_foo_inner(), the two variables are set to NULL.  For the block representing proc_foo_inner(empRow), the variables are set to the proper empRow values.

PROCEDURE dbo.PROC_FOO_OUTER 
AS 
 BEGIN 
 
 DECLARE 
 @empRow$LASTNAME nvarchar(40), 
 @empRow$FIRSTNAME nvarchar(20), 
 
 
 SET @empRow$LASTNAME = 'Smith' 
 SET @empRow$FIRSTNAME = 'John' 
 

 BEGIN /* proc_foo_inner() */ 
  DECLARE 
  @proc_foo_inner$row_a$LASTNAME nvarchar(max) 
 
  DECLARE 
   @proc_foo_inner$row_a$FIRSTNAME nvarchar(max) 
 
   SET @proc_foo_inner$row_a$LASTNAME = NULL 
   SET @proc_foo_inner$row_a$FIRSTNAME = NULL 
 
   BEGIN 
    PRINT 'Last name = ' + isnull(CAST(@proc_foo_inner$row_a$FIRSTNAME AS varchar(max)), 'NULL') 
    PRINT 'First Name = ' + isnull(CAST(@proc_foo_inner$row_a$LASTNAME AS varchar(max)), 'NULL') 
   END 
 END 
 

BEGIN /* proc_foo_inner(empRow) */ 
 DECLARE 
 @proc_foo_inner$row_a$LASTNAME$2 nvarchar(max) 
 
 DECLARE 
 @proc_foo_inner$row_a$FIRSTNAME$2 nvarchar(max) 

 
  SET @proc_foo_inner$row_a$LASTNAME$2 = @empRow$LASTNAME 
  SET @proc_foo_inner$row_a$FIRSTNAME$2 = @empRow$FIRSTNAME 
 
  BEGIN 
   PRINT 'Last name = ' + isnull(CAST(@proc_foo_inner$row_a$FIRSTNAME$2 AS varchar(max)), 'NULL') 
   PRINT 'First Name = ' + isnull(CAST(@proc_foo_inner$row_a$LASTNAME$2 AS varchar(max)), 'NULL') 
  END 
 END 
END 

Unfortunately we never had Sybase ASA on our plans for SSMA. The plan is still intact and we still support migration from Sybase ASE 11.9 onwards with the latest version of SSMA for Sybase http://www.microsoft.com/en-us/download/details.aspx?id=28765

 Even if we can’t use SSMA we still have a way to migrate in case only schema and data needs to be migrated (which is mostly the case). You can use a Linked Server to great advantage. The syntax between Sybase and MS SQL Server don’t differ much as they share the same DNA. Below are the providers that you can use to setup a linked server from SQL Server to Sybase ASA and then use queries to pull data and insert into the local database.  I am providing some information below to give you pointers for the same.   

a)      Have to install the required provider/driver on the SQL Server machine.

 Sybase ASA can be connected in following ways

 OLE DB Providers

 You need an OLE DB provider for each type of data source you wish to access. Each provider is a dynamic-link library. There are two OLE DB providers you can use to access Sybase IQ:  Sybase ASA OLE DB provider The Adaptive Server Anywhere OLE DB provider provides access to Sybase IQ as an OLE DB data source without the need for ODBC components. The short name for this provider is ASAProv. 

When the ASAProv provider is installed, it registers itself. This registration process includes making registry entries in the COM section of the registry, so that ADO can locate the DLL when the ASAProv provider is called. If you change the location of your DLL, you must reregister it. 

If you use the Adaptive Server Anywhere OLE DB provider, ODBC is not required in your deployment. 

ODBC Driver

Microsoft OLE DB provider for ODBC Microsoft provides an OLE DB provider with a short name of MSDASQL.

The MSDASQL provider makes ODBC data sources appear as OLE DB data sources. It requires the Sybase IQ ODBC driver.

 b)      Create a Linked Server and then query the same.

 This link species the steps and some common errors while setting the Sybase ASA Linked Server

 Steps :  http://sql-articles.com/articles/dba/creating-linked-server-to-sybase-from-sql-server/  (These are for ASE but are the same for ASA except that you have to choose a different provider/driver)

 Connection Issues : http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/fe29f12d-67b0-40a8-a41b-1767853a0185

Angshuman Nayak 

SSMA simplifies database migration process from Oracle/Sybase/MySQL and Microsoft Access to SQL Server and SQL Azure. SSMA automates all aspects of migration including migration assessment analysis, schema and SQL statement conversion, data migration as well as migration testing to reduce cost and reduce risk of your database migration project. 

The new version of SSMA – SSMA 5.3 provides the following major enhancements:

• Support of Migration to MS SQL Server 2014.
• Improved conversion mechanism when migrating to Azure.
• New features in the Migration GUI.
• No requirement to get a License key to start using SSMA.

Download SQL Server Migration Assistant (SSMA) v.5.3 :

Launch the download of the SSMA for Oracle.

Launch the download of the SSMA for Sybase.

Launch the download of the SSMA for MySQL.

Launch the download of the SSMA for Access.

The SSMA product team is available to answer your questions and provide limited technical support. Contact the team at ssmahelp@microsoft.com

SSMA simplifies database migration process from Oracle/Sybase/MySQL and Microsoft Access to SQL Server and SQL Azure. SSMA automates all aspects of migration including migration assessment analysis, schema and SQL statement conversion, data migration as well as migration testing to reduce cost and reduce risk of your database migration project. 

The new version of  SSMA, Version  6.0 provides the following major enhancements:

• Materialized View support for Oracle

• Memory Optimized tables for Oracle
• Improved Azure SQL DB code conversion
• Extension pack functionality moved to schema to support Azure SQL DB
• Performance improvements tested for databases with over 10k objects
• UI improvements for dealing with large number of objects
• Highlighting of “well known” LOB schemas (so they can be ignored in conversion)
• Conversion speed improvements
• Show object counts in UI
• Report size reduction by more than 25%
• Improved error messages for unparsed constructs.

 Download SQL Server Migration Assistant (SSMA) v.6.0

SSMA for Access:  http://www.microsoft.com/en-us/download/details.aspx?id=43690

SSMA for MySQL: http://www.microsoft.com/en-us/download/details.aspx?id=43688

SSMA for Oracle:  http://www.microsoft.com/en-us/download/details.aspx?id=43689

SSMA for Sybase: http://www.microsoft.com/en-us/download/details.aspx?id=43691

On the closing note , Yes ! We’ve heard several of your valuable feedbacks / inputs. Thank you… and we’re rolling out with the SSMA for DB2 very soon. Watch out this space for more information.

The SSMA product team is available to answer your questions and provide technical support related to SSMA. Contact the team at ssmahelp@microsoft.com

We are happy to announce the release of the most anticipated DB2 for SSMA. You can download the same from the link : http://www.microsoft.com/en-us/download/details.aspx?id=45296

We look forward to hear back from your end on the feedback related to the utility.

Microsoft has released an update to SSMA 6.0 for Oracle, DB2, Sybase ASE, MySQL and Access. SSMA simplifies the database migration process by automating all aspects of migration including migration assessment analysis, schema conversion, SQL statement conversion and data migration. SSMA also includes migration testing to reduce the cost and risk of database migrations.

Version 6.01 of SSMA includes the following enhancements:

• SSMA for Oracle.
• Added support for clustered indexes.
• Fixed performance with querying Oracle schema. 
• Fixed issues when setting up a connection to Azure from the console.
• SSMA for DB2.
• Fixed support for DB2 v9 zOS.
• Added support for more standard functions.
• Fixed issues when setting up a connection to Azure from the console.
• SSMA for MySQL.
• Updated driver support now includes newer versions of the ODBC driver greater than v5.1.
• SSMA for Access.
• Fixed handing of fields with a GUID datatype and a default function.
• Fixed issues importing records into an Azure SQL Database.
• New command in the menu to view the SSMA log file.
• This provides an easy way to get to the log file to help diagnose any issues that come up when using SSMA.

 Download SQL Server Migration Assistant (SSMA) v6.0.1

• SSMA 6.0.1 for Access:    http://www.microsoft.com/en-us/download/details.aspx?id=51214
• SSMA 6.0.1 for DB2:        http://www.microsoft.com/en-us/download/details.aspx?id=51216
• SSMA 6.0.1 for MySql:     http://www.microsoft.com/en-us/download/details.aspx?id=51218
• SSMA 6.0.1 for Oracle:    http://www.microsoft.com/en-us/download/details.aspx?id=51217
• SSMA 6.0.1 for Sybase:   http://www.microsoft.com/en-us/download/details.aspx?id=51215

For help and support using SSMA, please visit https://aka.ms/ssmahelp.

Microsoft has released a preview release of SQL Server Migration Assistant (SSMA) that supports migrating databases from Oracle, Sybase ASE, DB2, MySQL and Access to SQL Server 2016 Release Candidate 0. In this release, the following features have been added:

SSMA 6.1 Preview, all platforms:

• Support for SQL Server 2016 Release Candidate 0
• Support for running SSMA on Windows 10

SSMA 6.1 Preview for Oracle now supports Row Level Security including the following:

• Support loading of security policies from the Oracle Virtual Private Database (VPD)
• The Oracle VPD is represented in the SSMA UI with policy objects underneath
• The associated VPD attributes and predicate function are represented in the SSMA UI
• Support loading of security policies from SQL Server 2016
• SQL Server Security policies are represented in the SSMA UI and organized in categories
• The SQL Server Security policies associated attributes are represented in the SSMA UI
• Support for conversion of Oracle security policies to SQL Server security policies

SSMA 6.1 Preview for Oracle now supports In-Memory Tables and Column Store including the following:

• Support loading of in-memory tables shown in UI with ‘M’ icon
• Support conversion to selected SQL Server mapping:
  • Row-store table with Non-clustered Columnstore Index
  • In-memory OLTP tables
  • Clustered Columnstore Index-organized table
  • Row-store table without Columnstore Indexes

To download the SSMA 6.1 Preview release see the following links:

• Sybase ASE: http://www.microsoft.com/en-us/download/details.aspx?id=51472
• Oracle: https://www.microsoft.com/en-us/download/details.aspx?id=51471
• Access: http://www.microsoft.com/en-us/download/details.aspx?id=51473
• MySql: http://www.microsoft.com/en-us/download/details.aspx?id=51470
• DB2: http://www.microsoft.com/en-us/download/details.aspx?id=51469

Microsoft has released SQL Server Migration Assistant (SSMA) 7.0 which now supports migrating to SQL Server 2016 and has expanded support for Azure SQL Database.

All platforms:

• Support for SQL Server 2016
• Extended support for Azure SQL Database
• Support for running SSMA on Windows 10
• Fixed “save project” and “open project” commands for SSMA Console
• Fixed “securepassword” command for SSMA Console
• Fixed counting of objects for initial loading
• Removed installer check for .Net 2.0

Oracle

• Add conversion for in-memory tables and column store indexes to leverage In-Memory OLTP for SQL Server 2016 and In-Memory Columnstore for SQL Server 2016 and Azure SQL Database
• Added conversion of Oracle flashback archive tables to leverage SQL Server Temporal tables in SQL Server 2016 and Azure SQL Database
• Added conversion of Oracle VPD Policy converting to leverage Row Level Security in SQL Server 2016 and Azure SQL Database
• Decreased time of initial loading for Oracle
• Improved parser and resolver
• Updated Extension Pack dependency from .Net 3.5 to .Net 4.0

Db2

• Added conversion of DB2 in-memory tables and column store indexes to leverage In-memory OLTP for SQL Server 2016 and In-Memory Columnstore for SQL Server 2016 and Azure SQL Database
• Added conversion of DB2 access controls to leverage SQL Server Row Level Security for SQL Server 2016 and Azure SQL Database
• Added conversion of DB2 system-versioned tables to leverage SQL Server Temporal tables for SQL Server 2016 and Azure SQL Database
• Improved DB2 parser and resolver
• Removed unnecessary *.dll from Db2 installer

MySQL

• Improved parser and resolver
• Updated Extension Pack dependency from .Net 3.5 to .Net 4.0
• Fixed default BigInt typemapping for MySQL
• Fixed MsSql objects loading

MS Access

• Fixed tables data loading for UI tabs for Access
• Added support for disabling the loading of linked tables

Sybase ASE

• Updated Extension Pack dependency from .Net 3.5 to .Net 4.0

To download the SSMA 7.0 release see the following links:

• SSMA for MS Access
• SSMA for DB2
• SSMA for MySQL
• SSMA for Oracle
• SSMA for Sybase ASE

SQL vNext CTP1 on Windows and Linux is now a supported target platform for migration. This feature is in technical preview and will allow schema and data movement to the target SQL server.
Review the announcement here.