Troubleshooting

For information about possible workarounds or solutions for known issues that you might encounter while using the driver in various BI tools, see the following sections:

Architecture Mismatch Problems

If you encounter an error message similar to "The specified DSN contains an architecture mismatch between the Driver and Application", then the bitness of the application you are using to attempt to connect to the DynamoDB data store does not match the bitness of the driver that you are using. You might be attempting to connect a 32-bit application to a 64-bit driver, or vice versa. Make sure that the bitness of your application matches the bitness of driver that you are trying to use.

Note:

Applications in Microsoft Office 2007 and earlier are 32-bit only.

To determine the bitness of an application:

  1. Open the About dialog box for the application. For example, to open the About dialog box for Microsoft Office 2013 products, select the File tab in the ribbon, then click Account in the left pane, and then click the About [Application] button (where [Application] is the application name).
  2. In the About dialog box, look for the words 32-bit or 64-bit:
    • If the About dialog box contains 32-bit then you must use a 32-bit driver to connect to that application.
    • If the About dialog box contains 64-bit then you must use a 64-bit driver to connect to that application.

    For example, the following image shows the About dialog box for a 32-bit version of Microsoft Excel 2013.

    Determining the bitness of Excel 2013

Known Issues When Using Microsoft Office

The following are known issues that you might encounter when using Microsoft Query or Microsoft Access to work with your data.

Invalid Primary Keys

In Microsoft Access, if a table contains cells that show #Deleted as the value instead of the expected data value, then the table might be using an invalid primary key. To diagnose this issue, check the primary key values in the table and the data type of the primary key column, and verify if either of the following situations apply.

Primary Key Value is not Unique

Access does not allow primary keys to be used by more than one row in the same table. Each primary key in a table must be unique.

To resolve this issue, make sure that the table does not contain any rows that share the same primary key value.

Primary Key Column is of an Unsupported Type

Access does not support the following data types for primary key columns:

  • SQL_BIGINT
  • SQL_WCHAR
  • SQL_WVARCHAR
  • SQL_WLONGVARCHAR

To resolve this issue, convert the column to another data type, such as SQL_INTEGER or SQL_CHAR.

Invalid Column Names

In Microsoft Access, if you encounter an error message stating "[ColumnName] is not a valid name" (where [ColumnName] is the name of a column in your result set), then the column name contains special characters that are not supported by the application.

In Microsoft Query, this issue returns an error message stating "Qualified column could not be bound".

The issue might be caused by the separator characters that the driver uses when generating a schema definition. To resolve this issue, change the ODBC column name in the schema definition to a valid name, based on the following guidelines:

  • The column name starts with a letter of the alphabet or an underscore (_).
  • The column name only contains characters that are a letter of the alphabet, a number, or an underscore (_).

To rename columns in the schema definition:

  1. In the Schema Editor, open the local file containing the schema definition that you are using for the connection.
  2. In the left pane, select the table containing the column that has the invalid name.
  3. In the lower area of the right pane, find the column that has the invalid name, and then change the dsiiName value to a valid column name.
  4. Note:

    The dsiiName value is the column name that will be exposed in the ODBC layer.

  5. Save your changes to the schema definition.

After reconnecting to the data store using the new schema definition, you should be able to retrieve the column successfully.

Note:

For more information about using the Schema Editor, see the Schema Editor User Guide.

Known Issues When Using Linked Server

The following are known issues that you might encounter when using a SQL Server linked server to work with your data.

Scripting Options Return Errors

When using a linked server, the scripting options that are accessible from the Object Explorer are not supported. For example, if you try to execute a query using one of the Script Table As options, the Management Studio will return an error message stating that the specified table "contains no columns that can be selected or the current user does not have permissions on that object".

As a workaround for this issue, define your queries using the editor that opens when you click the New Query button in the toolbar instead of using the scripting options.

Type Conversion Error

If a type conversion error occurs after you try to execute a query, then the result set might contain a column that is longer than 8000 bytes. This issue occurs because the maximum data length that SQL Server supports is 8000 bytes.

To resolve this issue, modify your query to exclude the column from your result set.

Decreased Performance During Filtered Queries

When using a linked server, filtered queries might take longer than expected to execute. This issue occurs because the filters are being processed by the linked server; by default, the linked server does not pass filters to the Simba DynamoDB ODBC Driver.

To resolve this issue, modify your query to enclose the filters in the OPENQUERY function. When you execute a query with the filters contained in the OPENQUERY function, the linked server passes the filters to the driver for processing, improving performance.

For example, if you execute the following query, the linked server will process the filters:

SELECT TOP 100 * FROM [LINKEDDYNAMODB].[default].[FoodMart].[Sales]

To retrieve the same data but make sure that filtering is processed by the Simba DynamoDB ODBC Driver instead, execute the following query:

SELECT * FROM OPENQUERY(LINKEDDYNAMODB, 'SELECT TOP 100 * FROM Sales')

For more information about the OPENQUERY function, see the "OPENQUERY (Transact-SQL)" article in the Transact-SQL Reference: https://msdn.microsoft.com/en-CA/library/ms188427.aspx.