I have a table that is linked to MS SQL Server through an ODBC connection. From what I can tell, Access somehow determines the Field Size and data type. In one of my fields, Access decided to set the field size to 7, when it should be 8. For a number of records, the last digit is being truncated! Access also has set the Datatype to Short Text. When ever I try to change either of these fields, I get the error "Operation is not supported for this type." Does anyone know how access determines the field size/data type, and how to change it for an ODBC linked table?
Edit: In my SQL table, the data displays properly. The truncation only occurs after the ODBC link in Access. Data type is nvarchar(50)
is the field in question datetime2?
The standard "legacy" driver installed on windows by default (since xp days I think) does not see the later "newer" types of columns used in SQL server.
So, if you use SQL server driver, then Access will actually see that column as a string (text) and not a datetime column.
The fix is:
Use a native 11 or newer sql ODBC driver. This works, but then you have to ensure and install the native 11 (or later) driver on each workstation.
The other possible is to change the datetime2 to a datetime column server side, and re-link using the long time (and older) legacy SQL server driver.
However, even with the standard SQL driver installed by default on on recent editions of windows, I not seen the truncation you describe. I would suggest you try using a newer native 11 (or 13 or even later version). This may well fix your issue, but then you have to ensure that this newer driver of the same version is installed on each workstation.
I still use the legacy SQL server driver and thus this avoids me having to install a newer ODBC driver on each workstation, but in turn for this favor, I have to avoid the newer SQL server data column types available such as datetime2 columns.
I would try re-linking with a newer native 11 or later driver - see if that fixes this issue.
Related
I have a seemingly straight forward project, which unexpectedly faces many obstacles.
I need to move backend data of the existing Access 2016 application from Access to SQL Server 2016.
The challenges I face are:
The simplest and recommended way to migrate Access to SQL Server is using Microsoft SQL Server Assistant (SSMA) for Access. The problem is that my Access is 32-bit Click-to-Run edition. Because the target is SQL Server 2016, I should use SSMA for Access v.7.6.0, which is available only in 64-bit. To use it, I need to install 64-bit Access Runtime, which could not be installed, because per the error message “Windows Installer and Click-to-Run editions of Office programs don't get along”. The earlier version of SSMA for Access 6.0 comes in 32-bit and connects to Access fine, but could not connect to SQL Server 2016, as 2014 is the latest version it supports. Ignoring the warning and forcing the connection to SQL Server 2016 causes error collecting data… Thus, I could not use SSMA.
I was able to migrate the data from Access to SQL Server using SSIS. Now, my challenge is to repoint existing Access tables to their SQL Server copies. I was trying link, but it appears that existing Access tables could be linked only to the file system data source. If I try to make link from the SQL Server side, I could only create new linked tables, which do not do me much good as I am trying to avoid massive changes in the application. Could it be that I am missing something simple here?..
Some Access tables have columns of attachment data type. SSIS doesn’t handle attachment data type correctly. To the best of my knowledge, neither does SSMA. So, when I get to link Access tables to SQL Server, I would probably need to write some code to move attachments from the backup Access database to SQL Server. Is there some other an easier solution?
Any suggestions are greatly appreciated.
That is correct. It is a mess. You can use another (virtual) machine with a clean 64-bit Access install.
Delete the current tables in the frontend and link the SQL Server tables. They may be given a "dbo_" prefix which you can remove by renaming the tables.
This is a rewrite. Attachment fields are not supported in SQL Server. Neither are other fancy features like lookup fields and multivalue fields.
This is my first post in here,
I am new to SQL and I started learning it, I use it mainly in excel to get data from an outer Database
I first go to data then Refresh all then from the menu I choose connection properties
Then a dialogue appears and I input my code in the window called Command text from the Tab Definition
I added images to show where I input my SQL code
My question is what type of SQL do I input there ?
is it mySQL or SQLServer or what ??, so I can learn it, because some commands just don't work with me the way they are supposed to do
You can connect to any database type as long as you have the appropriate ODBC drivers. For example, here is documentation for MySQL for Excel. Quote from article "Use Microsoft Query to retrieve external data":
If the external database that you want to access is not supported by the
ODBC drivers that are installed with Microsoft Query, then you
need to obtain and install a Microsoft Office-compatible ODBC driver
from a third-party vendor, such as the manufacturer of the database.
Contact the database vendor for installation instructions.
OLAP databases do not require ODBC drivers. When you install Microsoft Query, drivers are installed for databases that were created
by using Microsoft SQL Server Analysis Services. To connect to other
OLAP databases, you need to install a data source driver and client
software.
Whichever database type you connect to, you will still be using Microsoft's SQL variant (as developed for SQL Server). As a beginner you're not going to notice too many differences right off the top. Most of the differences are related to data types, such as DATE vs DATETIME. Here is a wiki on SQL Compliance and this article on MS Access SQL will also apply to Excel Query.
You can connect to many data source including: SQL Server database, Access database, MySQL database, PostgreSQL database etc..
You can find the full list here: Link
I am having trouble gaining access to FileMaker Pro 11 data through the ODBC connection and starting to believe that it is not possible.
I have installed the odbc drivers supplied with the installation (11.03.76.00) locally to the FileMaker database, having worked out that they will not work remotely to the server. Have setup and successfully tested a system DSN.
When I try to use that System DSN within SQL Server or SSIS (same underlying process), I am gaining access to the list of tables and can preview the data, however when each process tries to get the metadata regarding the tables it fails.
SQL lets me select the tables / columns, preview the data, match it to destination and change the data types, but then fails on the next step of checking the conversion
SSIS provides list of tables / columns, data preview, but fails to list the columns (im guessing because it cannot work out the types)
FileMaker tech support does not cover the ODBC driver which has led me to believe it does not work...
Has anyone successfully attached to FileMaker Pro though the version 11 of the driver with SSIS or SQL? I need to automate a daily extract - any other ideas?
As billinkc points (above comment - sorry cannot convert comment into an answer), you can use the Script component as a Source and program around the ODBC driver issues.
The FileMaker Pro 11 odbc driver is data type aware, but they are not plumbed in correctly. The work around requires converting each column to string and then TryParse'ing to the correct data type.
I have a new server with the same Classic ASP code connecting to same SQL Server 2000 database with the same connection string yet it seems to be pulling data out of the database differently now. Specifically there is a custom encryption function which creates special characters (non-ASCII) and stores them in a VARCHAR field. (This is legacy code.) Since nothing has changed except the web server it has been hard to diagnose this problem.
Is there some setting that would control the database driver which would allow this data to come out of the database? It seems the character set is not treated the same with the new server as it was with the old server. Is there something I can change in the ODBC driver settings?
The server version change is from IIS 6 to IIS 7.5. The new server obviously also has new ODBC driver versions.
Any help is appreciated?
I suspect something to do with Locale rather than anything else. However I don't understand Locale. :-(
If it is a stored proc, a quick-fix might be to change the data type on the DB parameter/column to NVARCHAR. With ASP it will be unicode BSTR values in the application anyway, so moving the conversion into the database may make it easier to control, if necessary by specifying a collation to use for the conversion.
If you have the ASP code you could also edit the select to say cast(password as nvarchar(50)) as password or whatever to achieve the same result.
I got one problem from comparing database schema as i use Red gate SQL Compare 6 , after initialization of the compare databases error is coming as following
"Index was outside the bounds of the array".
Please provide your valuable comments to get resolve this issue.
Have you tried upgrading? The latest version released is 8.1, and your issue might have been fixed in the intervening versions. You can also try posting on their support forums...
Don't use version 6 on 64 bit versions of SQL Server... Or 7, it appears.
The computer running SQL Compare is using a 64-bit edition of Windows
One or more of the servers being compared are SQL Server 2005 or higher
The Decrypt encryped objects on SQL 2005 and 2008 databases option is selected
I've been using Redgate stuff since 2003 and don't remember this error.
I really would consider upgrading...
Try dbForge Scheme Compare for SQL server. It can compare and synchronize any database scheme. Quick, easy, always delivering a correct result. See how it flies on your database!