I have a SQL Server Agent job running, which uses a stored procedure to do several operations, then exports some data to an xls spreadsheet and emails that spreadsheet. Most of the time it works, but several times a month the job fails with the error:
OLE DB provider 'Microsoft.Jet.OLEDB.4.0' reported an error. The provider did not give any information about the error. [SQLSTATE 42000] (Error 7399). The step failed.
Thanks, Microsoft, for the detailed error message. Anyway, the short term fix is usually to simply re-run the job. Usually this works, but in rarer cases it does not, and I must restart the SQL Server instance.
Here is how my code interacts with OLEDB:
Insert into OPENROWSET('Microsoft.Jet.OLEDB.4.0', 'Excel 5.0;Database=\\Excel\POStatus\POStatus.xls;',
'SELECT * FROM [POStatus$]')
Select --Tons of columns with tons of math and functions
FROM --5 tables joined together (left joins)
WHERE -- Tons of where conditions
Order by --Case statement for custom sorting
Set #vCommand = 'copy \\Excel\POStatus\POStatus.xls \\Excel\POStatus\POStatus_' + #vDate + '.xls'
EXEC master..xp_cmdshell #vCommand , NO_OUTPUT
... omitted for brevity...
Set #nvSubject = ' POStatus ' + #vDate
Set #nvMessage = ' This is an automated message, please respond to the IS department, thank you '
Set #nvMessage = #nvMessage + char(13) + char(10)
Set #nvAttachments = '\\Excel\POStatus\POStatus_' + #vDate + '.xls'
Exec master..xp_sendmail
#recipients = #nvRecipients , #copy_recipients = #nvCopy_recipients ,
#subject = #nvSubject , #message = #nvMessage ,
#query = #nvQuery , #width = #iWidth , #attachments = #nvAttachments
So, what is the cause of this, and how can I prevent it?
When you call OPENROWSET, it load the DLL for OLEDB provider for Excel. These operations happens inside the SQL Server Stack memory. When a lot of call to older DLL (ActiveX/COM) are made, it's not impossible that your stack might get full. You can resolve this in 2 ways:
1) You make these operations outside a TSQL code. You can use a SSIS package for example but you have to change your code not to use OPENROWSET. You can use the DTS Wizard to do most of the job. This is my personnal recommandation !
2) You can also set SQL Server to have a bigger memory Stack by using the -g command parameter. I think 256 MB is the default and you can set it to 512. To do that you need to open the SQL Server Configuration Manager. Depending on your version, you should have a place to change the "Startup Parameters"
Related
When executing an SSIS package, the following error appears:
[OLE DB Source [83]] Error: The SQL command requires a parameter named
"#Sales_person", which is not found in the parameter mapping.
[SSIS.Pipeline] Error: OLE DB Source failed the pre-execute phase and
returned error code 0xC0207014.
Below is the screenshot of my OLE DB Source editor
I do see Param direction tab in Set Query parameters, how is that used? In my case will I be using Input or Output or InputOutput
After searching i didn't find a solution for this issue that worked for me. Ther are many suggestions like adding SET NOCOUNT ON before the execute command. Below some related links:
http://geekswithblogs.net/stun/archive/2009/03/05/mapping-stored-procedure-parameters-in-ssis-ole-db-source-editor.aspx
http://www.sqlservercentral.com/articles/Data+Flow+Task+(SSIS)/117370/
http://www.ssistalk.com/2007/10/10/ssis-stored-procedures-and-the-ole-db-source/
You can do a workaround
Declare a SSIS variable (assuming #[User::Query])
Set #[User::Query] property EvaluateAsExpression = True and use the following expression
"EXEC [dbo].[GetDales_Person_data] " + #[User::Sales]
if #[User::Sales] is a string use the following
"EXEC [dbo].[GetDales_Person_data] '" + #[User::Sales] + "'"
Then In OLEDB Source use SQL Command from variable and select #[User::Query]
The problem is with the mapping. See image and source below to make corrections, you should set it to:
Exec [dbo].[GetSales_Person_Data] #Sales_person = ?
Source - geek with blogs
There seems to be a problem with mapping parameters directly into the EXEC statement.
One way you can get around this is to use:
DECLARE #SalesPerson int = ? -- or whatever datatype
EXEC [dbo].[GetSales_Person_Data] #SalesPerson
I have a program that fails intermittently in a complex query.
The error reads:
System.Data.SqlClient.SqlException: Cannot fetch a row from OLE DB provider "MSDASQL" for linked server "LinkedServer".
The query looks like this:
SELECT Replace([JOB-NO],'M0','') as KeyTaskID,
dbo.SFGET_UniqueTaskID([CLIENT-CODE],Replace([JOB-NO], 'M0', ''), 0, [TRADE-CODE]) AS HMSUniqueTaskID,
[LATEST-PRIORITY] AS PriorityCode,
[KeyProperty] AS KeyProperty,
Replace([JOB-NO],'M0','') AS KeyJob,
[JOB-TYPE] as TaskSubType,
CONVERT(varchar(6),[MAINT-OFFICER]) AS Officer,
LEFT(FORENAME + ' ' + SURNAME, 50) AS OfficerName,
[JOB-NO] + ' ' + LEFT(RTRIM(REPLACE([TEXT-LINE], ';', CHAR(13))), 480) AS Description,
dbo.SFGET_FormattedDate([TARGET-DATE],0) AS DueDateTime,
[CURRENT-STAGE-CODE] AS CurrentStageCode
FROM openquery(LinkedServer, '
SELECT DISTINCT
"RM-JOB"."JOB-NO",
"RM-JOB"."CLIENT-CODE",
"RM-JOB"."LATEST-PRIORITY",
"RM-JOB"."TRADE-CODE",
"RM-JOB"."JOB-TYPE",
"RM-JOB"."TARGET-DATE",
"RM-JOB"."MAINT-OFFICER",
"RM-JOB"."TEXT-LINE",
"RM-JOB"."CURRENT-STAGE-CODE",
"RM-JOB"."PLACE-REF",
"IH_OFFICER".FORENAME,
"IH_OFFICER".SURNAME
FROM "PUB"."RM-JOB"
LEFT OUTER JOIN "PUB"."IH_OFFICER"
ON ("IH_OFFICER"."OFFICER-CODE" = "RM-JOB"."MAINT-OFFICER")
WHERE "RM-JOB"."JOB-TYPE" = ''GASS''
AND "RM-JOB"."JOB-STATUS" = 06
AND "RM-JOB"."CONTRACTOR" = ''NWH001'' ') as ibsTasks
INNER JOIN [SVSExtract].[dbo].Property prop
ON ibsTasks.[PLACE-REF] = prop.UserCode
I have been testing it manually using SQL Server Management Studio. It occassionally fails but it mainly works OK.
I am at a loss as to how I can debug an error that I cannot reproduce at will.
Any suggestions?
I'm not that proficient in SqlClients and Progress myself but: the Progress Knowledgebase might give you a solution!
This entry for instance describes a similar error, even if the version mentioned might be older than the one you use? (Always post version when asking about OpenEdge - there's lots of older installations out there and Progress has evolved quite a bit during the last couple of years).
The Knowledgebase is honestly best searched using Google:
Search for instance: site:knowledgebase.progress.com MSDASQL and you'll get 48 results.
I am making new Azure databases now and then and without any human interaction, by using a template database and azure copy database t-sql script.
After reading a few caveats I wonder what is the best way to wait for the copied database to be ready.
I have posted my own answer but it could end up in an infinite loop if the database copy fails.
What is the best way to be sure that the copying is done. This is very important as you are only allowed one copy database command at a time. I'm using an Azure worker with a c# queue that creates the databases as nessesary.
This is how I'm doing it now. This should work but unfortunatly errors when copying are rare.
declare
#sName varchar(max),
#sState varchar(max),
#iState int,
#sDbName varchar(50)
set #sDbName = 'myDbName'
set #iState = 7 --copying
while #iState = 7
begin
WAITFOR DELAY '00:00:05'
SELECT #sName = name, #iState = state, #sState = state_desc FROM sys.databases WHERE name = #sDbName
end
SELECT name, state,state_desc FROM sys.databases WHERE name = #sDbName
This code is actually run from a Azure worker in c#
Edit:
If you want more granular approch use sys.dm_database_copies
But otherwise remember that this sql returns the state as integer, and its only successfull if the state ==0 Othervise the copy has failed.
the states are:
0 = ONLINE
1 = RESTORING
2 = RECOVERING
3 = RECOVERY_PENDING
4 = SUSPECT
5 = EMERGENCY
6 = OFFLINE
7 = COPYING (Applies to Windows Azure SQL Database)
Windows Azure SQL Database returns the states 0, 1, 4, and 7.
I'm trying to paramaterize some queries in SSIS. After some reading, it sounds like my best option is to create one variable that contains my base sql, another that contains my criteria and a final variable that is evaluated as an expression that includes both of these. I want to end up with an SQL query that is effectively
UPDATE mytable set something='bar' where something_else='foo'
So my first two variables have the scope of my package and are as follows:
Name: BaseSQL
Data Type: String
Value: UPDATE mytable set something = 'bar' where something_else =
Name: MyVariable
Data Type: String
Value: foo
My third variable has a scope of the data flow task where I want to use this SQL and is as follows:
Name: SQLQuery
Data Type: String
Value: #[User::BaseSQL] + "'" + #[User::MyVariable] + "'"
EvaluateAsExpression: True
In the OLE DB Source, I then choose my connection and 'SQL command from variable' and select User::SQLQuery from the dropdown box. The Variable Value window then displays the following:
#[User::BaseSQL] + "'" + #[User::MyVariable] + "'"
This is as desired, and would provide the output I want from my DB.
The variable name dropdown also contains User::BaseSQL and User::MyVariable so I believe that my namespaces are correct.
However, when I then click preview, I get the following error when configuring an OLE DB Source (using SQL command from variable):
TITLE: Microsoft Visual Studio
Error at Set runtime in DB [Set runtime in myDb DB [1]]: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80040E14.
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80040E14 Description: "Statement(s) could not be prepared.".
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80040E14 Description: "Must declare the scalar variable "#".".
(Microsoft Visual Studio)
Can anyone advise what I'm missing or how I can resolve this please ?
Thanks in advance!
I had a similar issue.
It seems to be that the designer wants something at design time.
I was getting the error when i tried to click OK on the oleDBSource task after choosing a variable name.
I had a similar situation where the where clause logic was a bit involved and required a script task to assign its value.
This is what things looked like at design time.
#basesql = "select from mytable where "
#where = empty string
#fullsql = #basesql + #where
i was getting the E14 error you mentioned above.
by changing the design time value of #where to something silly, the oleDBSource task got what it wanted and let me use the variable.
#where = " value1 is null and value2 = 'easteregg' "
Related issue, to even get the thing to work, i had to start out by putting a basic select stmt into the sql command so it could go get source columns.
It makes sense, but that step took me and google a while to figure out.
You should set the Expression property of SQLQuery, instead of the Value property. If you do it correctly, the Variable Value window should show you the result of the expression:
UPDATE mytable set something = 'bar' where something_else = 'foo'
I would create a script task and concatenate the strings into one variable and use that as your source:
Dts.Variables["SQLQuery"].Value = Dts.Variables["BaseSQL"].Value.ToString() +
Dts.Variables["MyVariable"].Value.ToString();
Then, in the advanced properties under the component properties tab, you need to change the ValidateExternalMetadad property to False so SSIS will not try to prevalidate your sql query in your variable which would give you a run time error. Just created a simple package and that seemed to work. Hope this helps.
-Ryan
Essentially I have a job which runs in BIDS and as as a stand lone package and while it runs under the SQL Server Agent it doesn't complete properly (no error messages though).
The job steps are:
1) Delete all rows from table;
2) Use For each loop to fill up table from Excel spreasheets;
3) Clean up table.
I've tried this MS page (steps 1 & 2), didn't see any need to start changing from Server side security.
Also SQLServerCentral.com for this page, no resolution.
How can I get error logging or a fix?
Note I've reposted this from Server Fault as it's one of those questions that's not pure admin or programming.
I have logged in as the proxy account I'm running this under, and the job runs stand alone but complains that the Excel tables are empty?
Here's how I managed tracking "returned state" from an SSIS package called via a SQL Agent job. If we're lucky, some of this may apply to your system.
Job calls a stored procedure
Procedure builds a DTEXEC call (with a dozen or more parameters)
Procedure calls xp_cmdshell, with the call as a parameter (#Command)
SSIS package runs
"local" SSIS variable is initialized to 1
If an error is raised, SSIS "flow" passes to a step that sets that local variable to 0
In a final step, use Expressions to set SSIS property "ForceExecutionResult" to that local variable (1 = Success, 0 = Failure)
Full form of the SSIS call stores the returned value like so:
EXECUTE #ReturnValue = master.dbo.xp_cmdshell #Command
...and then it gets messy, as you can get a host of values returned from SSIS . I logged actions and activity in a DB table while going through the SSIS steps and consult that to try to work things out (which is where #Description below comes from). Here's the relevant code and comments:
-- Evaluate the DTEXEC return code
SET #Message = case
when #ReturnValue = 1 and #Description <> 'SSIS Package' then 'SSIS Package execution was stopped or interrupted before it completed'
when #ReturnValue in (0,1) then '' -- Package success or failure is logged within the package
when #ReturnValue = 3 then 'DTEXEC exit code 3, package interrupted'
when #ReturnValue in (4,5,6) then 'DTEXEC exit code ' + cast(#Returnvalue as varchar(10)) + ', package could not be run'
else 'DTEXEC exit code ' + isnull(cast(#Returnvalue as varchar(10)), '<NULL>') + ' is an unknown and unanticipated value'
end
-- Oddball case: if cmd.exe process is killed, return value is 1, but process will continue anyway
-- and could finish 100% succesfully... and #ReturnValue will equal 1. If you can figure out how,
-- write a check for this in here.
That last references the "what if, while SSIS is running, some admin joker kills the CMD session (from, say, taskmanager) because the process is running too long" situation. We've never had it happen--that I know of--but they were uber-paranoid when I was writing this so I had to look into it...
Why not use logging built into SSIS? We send our logs toa database table and then parse them out to another table in amore user friendly format and can see every step of everypackage that was run. And every error.
I did fix this eventually, thanks for the suggestions.
Basically I logged into Windows with the proxy user account I was running and started to see errors like:
"The For each file enumerator is empty"
I copied the project files across and started testing, it turned out that I'd still left a file path (N:/) in the properties of the For Each loop box, although I'd changed the connection properties. Easier once you've got error conditions to work with. I also had to recreate the variable mapping.
No wonder people just recreate the whole package.
Now fixed and working!