I am currently using Teradata SQL Assistant 16.20 to connect to different databases. I am able to connect to Teradata database since Teradata SQL Assistant recognizes the 32-bit odbc data source; However, when I added a 64-bit data source for both oracle and Teradata, it does not recognize them at all.
I am ok with using the Teradata 32-bit data source but I want to use the 64-bit oracle. (Not able to add oracle data source under the 32-bit ODBC Data Source Administrator since it is not listed.) How can I approach this? Is 64-bit data source connections supported?
Related
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
Searched the net in and out and could not find proper info on that, we have a legacy setup that uses Delphi 7 and BDE to connect to SQL Server 2005.
Now we are planning to migrate to SQL Server 2012, what are the chances that it might work or not?
If you are using the SQL Links MSSQL driver then targeting SQL Server 2012 will not be possible. The only way that I have been able to use SQL Links with anything newer than SQL Server 2000 is to keep the database compatibility level set to "SQL Server 2000 (80)". This is not possible in SQL Server 2012. The oldest compatibility level available in this version is "SQL Server 2005 (90)".
SQL Links will send invalid SQL to the server, such as the "*=" syntax for an outer join. Databases set for SQL Server 2005 and above will not accept this syntax.
We've been using Delphi 7 with SQL Server 2012 without significant issue via the Delphi 7 ADO data control components (e.g. TAdoQuery, TAdoCommand). Stored procedures also work fine, and functions can be called via ADO commands objects (TAdoCommand).
We use the SQL Server Native Client 11.0 ODBC driver that comes with SQL Server 2012. Delphi just treats it as another ODBC data interface. Superficially it looks a lot like using MS Access with Delphi 7 (via ADO components and Access OLE driver). No issue with any of the Service Pack(s?) for SQL Server 2012 either. (Sorry, I don't remember exactly what SP's are released for 2012, but we've had no differences w/ or w/o these SP's, and we tested for it).
Most of the development was done on Windows 7 64-bit OS's, and executed on same as well as Windows Server 2008 and 2008R2, both 64-bit. No special settings were required to execute Delphi-compiled executables (which are all 32-bit, obviously).
If you use ODBC "aliases", be sure to use the 32-bit ODBC DSNs, not the 64-bit ODBC DSNs. The 64-bit ODBC Administrator is the one in the Control Panel\Administrative Tools for 64-bit Windows - don't use it here. Use the 32-bit ODBC Administrator, in Windows' SysWOW64: C:\Windows\SysWOW64\odbcad32.exe. The 64-bit ODBC DSNs live in a separate space from the 32-bit DSNs. Delphi 7 is a 32-bit application and won't have access to the 64-bit DSNs (different API I'm guessing).
We may also have had an issue with comments in SQL statements. I think the line comments ("--") didn't work, but multi-line comments worked ("/.../").
Note that while the BDE is preserved by Corel (distributed to this day as the Paradox Runtime; the engine is frozen, however, and does have some issues in modern Windows OS's), it's not needed to access SQL Server data. We use the ODBC aliases directly through the Windows ODBC API (we wrote wrappers in Delphi to make this trivial). However, you can still use the BDE as an interface to these ODBC DSN aliases. If you don't use aliases at all (and don't include any references to DbTables.pas in the source code) you shouldn't need the BDE at all. DbTables.pas initialises the BDE always when it initialises the global Sessions variable in its INTIALIZATION block. You can see this in the bottom of the DbTables.pas source code unit. Without this unit, the BDE isn't initialised or used. (Which also means you cannot use TTable or TQuery components, but those are only for Paradox data; the ADO components like TAdoTable (don't use it unless you want to load the entire data table into memory!), TAdoQuery or TAdoCommand are entirely independent.
Another trick is to use MS Access databases and linked tables to interface between SQL Server and Paradox data tables, if you still need to use BDE-native (i.e. Paradox) tables. But sometimes Access and the BDE don't play well together.
The migration is long done, I'm sure, but in case others are searching for the same answer. Legacy software has a habit of living on...
We've had success using BDE with SQL Server 2008R2. No special config.
Edit: I'm also having initial success on SQL Server 2014 today. Limited testing, but so far so good!
Greg
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 am building a SQL Server 2005 Integration Services package to migrate data from a Sybase Adaptive Server Enterprise 12.5.4 database to a SQL Server 2005 Database. The Sybase Database is the backend for a vendor product which our team does not have the authority to change or manage.
In my initial stages of development, to access the Sybase database, I created a SQL Server Linked Server utilizing the Microsoft OLE DB Provider for ODBC Drivers on my destination database server. With this linked server created, I created my SSIS package with a single Data Source - connecting to the MS SQL Server "Destination" Database. Next, in my SSIS package data flow tasks, I configured the OLE DB Source to access single Data Source defined in the package, using SQL commands to access the source linked server (simply using SELECT col1, col2, col3 FROM [SybaseLinkedServer].[Database].dbo.[Table]). The OLE DB Destination within the data flow task utilizes the same connection manager as the OLE DB Source, but makes use of the Table or view - fast load Data access mode.
Later, in the project, I obtained the Sybase ASE OLE DB Provider (The v12.5.4 OLE DB Provider was no longer available, we had to purchase the v15.7 ASE SDK). Thinking that removing the Linked Server from the solution would improve performance, I modified the SSIS package to include a new OLE DB Data Source utilizing the Sybase ASE OLE DB Provider to access the Sybase Database directly, and modified the OLE DB Source to use the new ASE OLE DB Data Source with the Table or View Data access mode.
To my surprise, switching the solution from the Linked Server using the OLEDB Provider for ODBC Drivers to the direct OLEDB connection using the Sybase ASE OLEDB Provider produced significantly poorer results, far from my expectations. The results from test runs using each method are available at this hyperlink.
Has anyone experienced this type of issue and/or is this behavior to be expected? Is there a better way to configure this to extract data from Sybase ASE to MS SQL Server 2005?
i had the exact same issue and i ended up using linked server to connect to sybase because it was the fastest way and most reliable, i had great difficulty trying to connect to sybase using SSIS sql 2008 directly.
even though i was able to connect to sybase using Sql 2000 DTSs.
but there is a very interesting driver provided by datadirect
http://www.datadirect.com/products/other/ssis/index.html
i downloaded it and tried it for 30 days, and it was amazing fast and very easy
its very light when comparing it with sybase drivers, i mean not much to install and it works very good with SSIS.
I want to migrate a Btrieve Database to Microsoft SQL Server 2008 R2. I already have done the step of migration to Pervasive PSQL 10 Workstation (x86), which offers an ODBC / OLE DB driver. (It seems Microsof doesn't offer any solution to import Btrieve.)
Ok, so far so good, but how can I transfer the whole database (schema and data) into Microsoft SQL Server? The Import Wizard of SQL Server crashes every time and is useless, because it doesn't map Date- and Memo-Datatypes correctly. I also tried to map these datatypes manually, but the wizard always crashes, caused by ODBC-Errors.
So, I'm looking for a tool which offers a native driver to Btrieve or PSQL 10. It would be nice if it is free, because I only need it for this single migration.
TIA! ^^
There is a tool with a Btrieve driver but you still need the DDFs (just like in ODBC) available from Pervasive called Data Integrator. It is not free but you can find more information at http://integration.pervasive.com/.
Another more manual option would be to export the data from PSQL to CSV, then import the CSV to the MS SQL server. You would have to manually create the tables in the MS SQL database but it could be done with the tools you have.
Also, you say it's crashing with ODBC errors. Are the ODBC errors from PSQL or MS SQL? What are they?