I am running Windows Server 2003 R2 Enterprise Edition SP 2
I have created an integration package in VS 2005 which extracts data from Excel and imports it into a table on SQL server 2005 running on this server.
The package runs ok in Visual Studio 2005,I did a bit of research which suggests this is due to SQL 64 bit and Windows 64b bit, however I am running 32 bit !!
Description: An OLE DB error has occurred. Error code: 0x80040154.
An OLE DB record is available. Source: "Microsoft OLE DB Service Components" H
result: 0x80040154 Description: "Class not registered".
End Error
Error: 2010-01-04 16:02:19.14
Code: 0xC00291EC
Source: Delete from ExcelDB Execute SQL Task
Description: Failed to acquire connection "Co
nnection may not be configured correctly or you may not have the right permissio
ns on this con
Please help to resolve this issue
A couple of suggestions of things you could try
It says that its failing on 'Microsoft OLE DB Service Components'. Can you identify this component, and include it in a simple C#/VB.NET project. Perform a simple test within the project code, e.g. instantiate it and call a method. Then compile this to an EXE, transfer across to your server, and run it there.
The next thing to try is to trace the fault using Process Monitor:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
This is not for the faint hearted, as you could get tens of thousands of entries, but its possible to narrow the entries down:
1) Turn trace off and clear all your entries before you start.
2) Start the trace then quickly, start your package (e.g. have a command line keyed up)
3) Stop the trace as quickly as possible once you get the errors.
With any luck you might be able to determine where exactly the failure is occurring. This tool has been invaluable in the last few months, and I've followed similar step on a number of occasions.
Good luck
Related
I am using Data Migration Assistant to assess compatibility issues migrating a SQL database to Azure SQL. After running for a couple of minutes, it throws an error saying "The file contains the XML node type {0}. This type is unsupported or in an unsupported location." I have successfully assessed other databases using DMA but this particular database always aborts after throwing this error.
I decided to go ahead and migrate the database using the wizard (Deploy Database to Microsoft Azure SQL Database) from SSMS, and ran into several compatibility issues that showed as errors. The database had several triggers that were created by a third-party database tool that referred to table objects with the 3 & 4-part naming conventions which is not supported on Azure SQL. There were several other errors in addition to these but I decided to delete these triggers first and run Data Migration Assistant again. This time it ran to completion and I got compatibility report. I am not sure if it was the sheer number of issues found or something in those triggers that I deleted had caused the error.
I've been using SSMS, SQL Server Profiler and SQL Operations Studio for a while now without issue. However, when some query text (TextData column) was getting truncated in the profiler, I decide to increase the SSMS "XML Data" size to "5 MB". Now all three applications hang at different spots.
SSMS and SOS hang when scripting table as a SELECT.
SQL Profiler hangs after moving past the connection dialog.
In event viewer, I see this error:
Application: ioc.exe
Framework Version: v4.0.30319
Description: The
process was terminated due to an unhandled exception. Exception Info:
System.AccessViolationException
It's also important to note, it is definitely not the case that the trace window/connection dialog/etc. is rendering off screen. Simply, the applications are hanging due to an unhandled exception.
Restoring Query Results options to default didn't work.
Relaunching SSMS/SQL Server Profiler/Sql Operations Studio didn't work.
Rebooting didn't work.
Running applications as Administrator didn't work.
I ended up pointing the connection dialog to another database to see if that made a difference and I was able to connect. This seems to have jarred something loose; I had to do this for all three applications separately, each time performing the task that hung on prior attempts on a different server fixed the problem. Though I wish I knew what was happening under the covers, I wasn't able to find any resources describing this same issue.
Once I pointed back to the original database I was able to launch each application successfully.
UPDATE - I later found that ioc.exe is Intel's Lenovo bloatware (Intel Online Connect). A security suite, which I promptly uninstalled.
I need to create a procedure to upload data from an MS Excel spreadsheet to SQL server on command. My background is in Access VBA I am attempting to use either of the below Distributed Query methods as described on the Microsoft support website: (https://support.microsoft.com/en-us/help/321686/how-to-import-data-from-excel-to-sql-server). My table name and filename are different, otherwise I am using the exact code below. I receive the error: The OLE DB provider "Microsoft.ACE.OLEDB.4.0 has not been registered." I've tried other OLEDB versions to no avail. Not sure how to check which version of the driver I need. The SQL server that I am working with is 64 bit but my local machines are 32 bit and I think this is causing issues. If anyone can help simplify this issue and point me in the right direction I would much appreciate it. I am well versed in VBA with some SQL background. Other than that I don't have much programming background. Thank you!
SELECT * INTO XLImport3 FROM OPENDATASOURCE('Microsoft.Jet.OLEDB.4.0',
'Data Source=C:\test\xltest.xls;Extended Properties=Excel 8.0')...[Customers$]
SELECT * INTO XLImport4 FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0',
'Excel 8.0;Database=C:\test\xltest.xls', [Customers$])
The query:
SELECT * INTO [TableName]
FROM OPENDATASOURCE( 'Microsoft.ACE.OLEDB.12.0', 'Excel 12.0 Xml; Database=' + [SpreadsheetFullPath] + ';IMEX=1'' )...[' + [WorksheetName] + '$]'
Notes:
Keep in mind that the query is executed on the SQL server so [SpreadsheetFullPath] is the path on the server and not the local machine.
UNC paths (\\sharedDir\...) are accepted.
Keep Excel worksheets to be imported simple.
When something fails, the errors returned by this driver are very unhelpful, so try to avoid them by observing 3.
You may need to install drivers on the database server: Office 2010, Office 2016
There is a bigmuscled engine called SSIS (Sql Server Importing Services) that does this, with error reporting, transformation of data, scheduling etc. It may already exist on your server. This is not the place to describe it in detail but there are tutorials on youtube. During the years the design environment has either been standalone or a plugin in Visual Studio.
It will sure solve your importing problems, but there is a (steep) learning curve. (Which may pay off in you increased skills!). After SSIS you can continue to SSRS and SSAS but that is another story!
Your current problem is the driver name in the "connection string". It often depends on your server's OS-version. (I.e. what has (not) been installed). Instead of guessing (as I have done, developing on XP and at first deploying blindly on Win7 and Win10), I suggest you ask your Admins to on your server make a ODBC connection DSN file connecting to that Excel file of yours, and then look at the contents of that DSN file. It will contain the connection string and the driver name you are looking for, that suits your server's installation. I have also found that "default port#" may suddenly be required in the string as well when connecting to Sql Server.
Problem: Could not find installable ISAM
I am executing a query from MS Access in order to pull information from MS SQL Server 2005.
When I attempt to open a linked ODBC connection to the table directly it opens with no issues. However, when I attempt to create a DSN-less connection, I receive an ISAM error.
I have the following error when I attempt to execute my SELECT query:
"Could not find installable ISAM."
The code I'm using is as follows:
SELECT * FROM [Driver={SQL Server};
Server=Server_Name\Instance;
Database=Database_Name;
Integrated Security=SSPI;].[My_View_Name]
The help from MS Access provides the following information:
Could not find installable ISAM. (Error 3170)
The DLL for an installable ISAM file could not be found.
This file is required for linking external tables (other than ODBC or Microsoft
Jet database tables). The locations for all ISAM drivers are
maintained in the Microsoft® Windows® Registry. These entries are
created automatically when you install your application. If you change
the location of these drivers, you need to correct your application
Setup program to reflect this change and make the correct entries in
the Registry.
Possible causes:
+ An entry in the Registry is not valid. For example, this error occurs if you are using a Paradox external database, and the Paradox
entry points to a nonexistent directory or driver. Exit the
application, correct the Windows Registry, and try the operation
again.
+ One of the entries in the Registry points to a network drive and that network is not connected. Make sure the network is available, and
then try the operation again.
I have also found KB articles from Microsoft explaining when and how this should be handled. However they are unclear to me if they are actually rooted from another type of issue.
For example:
283881 and 209805 Tell me the purpose of ISAM is to tell how to format data other then, MS Access' native formatting. (But I don't want to format it in another way and the other formats do not list what I think to be the appropriate format-er)
and, 90111 Tells us the driver in the .ini file may be pointing to the wrong place in MS Access 2.0 which no longer exists in version 97+.
The odd thing is I have a DNS-less setup for another table which works fine. The only difference I see here is the default naming of the database object is not standard, so possibly I am not referring to the schema correctly in my syntax.
What am I doing wrong here? Is it truly a syntax error?*
Are there any "View" permission considerations which need to be made on the server end?
Try adding ODBC; at the start of the connection string and remove the brackets around the view name:
SELECT * FROM [ODBC;Driver={SQL Server};
Server=Server_Name\Instance;
Database=Database_Name;
Integrated Security=SSPI;].My_View_Name
I've just installed DB2 v8.1.18.980. Now I try to create new database. I'm getting the error with the following sql codes:
sqlcode : -902
sqlstate : 58005
Unfortunately the error itself in Russian, as a result, I cannot paste it here. Official site says the following about the problem:
"The statement cannot be processed. The application program is not permitted to issue additional SQL statements. For example, a recovery routine associated with the application program may not issue additional SQL statements.
Programmer response
Rebind the failing application program and try again. If the problem persists, examine your DBRM and make sure it matches your program."
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2z9.doc.codes/src/tpc/n902.htm
But, it's not clear to me. Any ideas, what can be wrong and how to resole it?
I'm using Windows 7 Ultimate if it may be an issue.
The documentation you linked to is for db2 v9 for z/os, not db2 v8 for Windows. So that's the first problem.
The documentation for v8 has this to say about SQL 902:
A system error (reason code = reason-code) occurred. Subsequent SQL statements cannot be processed.
Explanation:
A system error occurred.
User Response:
Record the message number (SQLCODE) and reason code in the message.
If trace was active, invoke the Independent Trace Facility at the operating system command prompt. Then contact your technical service representative with the following information:
Problem description
SQLCODE and embedded reason code
SQLCA contents if possible
Trace file if possible.
Federated system users: isolate the problem to the data source failing the request (refer to the Troubleshooting Guide to determine which data source is failing to process the SQL statement) and take the necessary diagnostic steps for that data source. The problem determination procedures for data sources vary, so refer to the applicable data source manuals.
sqlcode: -902
sqlstate: 58005
Which brings us to the second problem: it's asking you to contact IBM and open a ticket, and as far as I know v8 is out of support so it won't be that easy.
I think installing v9, v9.5 or v9.7 would be your best bet, unless you have a really compelling reason to stick with 8.