I am trying 30 days free trial of Chilkat and I am not getting any results in SQL, nor error information (unless it is a string text value, hardcoded). I have installed the module on the server and it confirms correctly
For example this piece of code with obviously incorrect address just runs through without any feedback (the code is from their tutorial - apart from the address - so should be technically correct)
DECLARE #hr int
DECLARE #iTmp0 int
DECLARE #sTmp0 nvarchar(max)
DECLARE #rest int
EXEC #hr = sp_OACreate 'Chilkat_9_5_0.Rest', #rest OUT
IF #hr <> 0
BEGIN
PRINT 'Failed to create ActiveX component'
RETURN
END
-- Connect to the REST server.
DECLARE #bTls int
SELECT #bTls = 1
DECLARE #port int
SELECT #port = 443
DECLARE #bAutoReconnect int
SELECT #bAutoReconnect = 1
DECLARE #success int
EXEC sp_OAMethod #rest, 'Connect', #success OUT, 'www.incorrect_address.co', #port, #bTls, #bAutoReconnect
IF #success <> 1
BEGIN
EXEC sp_OAGetProperty #rest, 'LastErrorText', #sTmp0 OUT
PRINT #sTmp0
EXEC #hr = sp_OADestroy #rest
RETURN
END
the Global Unlock method returns message that it is working
'Unlocked in trial mode.'
do you have any idea why it does not work? Any messages hardcoded (like 'unlocked in trial mode') are working but anything that should return values of objects - does not. I have of course enabled Configuration option 'Ole Automation Procedures' in SQL
Slav
The contents of the LastErrorText property is likely too large for limits imposed by sp_OAGetProperty. Try using a temp table like this:
DECLARE #tmp1 TABLE (lastErrText ntext)
INSERT INTO #tmp1 EXEC sp_OAGetProperty #rest, 'LastErrorText'
SELECT * from #tmp1
I want to return a value from a dynamic linked server stored procedure.
--storedprocedure on the remote linked server
ALTER PROCEDURE [dbo].[SPTEST]
#DocNumOut VARCHAR(20) output
AS
BEGIN
SET NOCOUNT ON;
SELECT #DocNumOut=1;
RETURN #DocNumOut
END
On the local server, how can I retrieve the value of #DocNumOut? I have trial many combination using EXEC, openquery, EXEC sp_executesql, but none can return the value into my local variable, #DocNumberOUT.
--local server
DECLARE #DocNumberOUT as int;
DECLARE #SQLCMD AS VARCHAR(2000)='EXEC LinkedServer.MyDB.dbo.SPTEST'
EXEC #DocNumberOUT= sp_executesql #SQLCMD
--Procedure expects parameter '#statement' of type 'ntext/nchar/nvarchar'.
Use OUTPUT parameter on your Stored Procedure and don't use the return value.
Use the proper data type. Don't use varchar for everything. Since you assigned an integer to the variable, declare it as integer.
ALTER PROCEDURE [dbo].[SPTEST]
#DocNumOut INT output
AS
BEGIN
SET NOCOUNT ON;
SELECT #DocNumOut=1;
END
On the calling side, the error message is telling you that #SQLCMD should declare as NVARCHAR. Using sp_executesql is the right choice. But you should also define the parameters and pass in the variable also. #DocNumOut is the name of the parameter that you defined in SPTEST. #DocNumberOUT is your local variable
DECLARE #DocNumberOUT as int;
DECLARE #SQLCMD AS NVARCHAR(2000);
SET #SQLCMD = 'EXEC [LinkedServer].[MyDB].[dbo].[SPTEST] #DocNumOut = #DocNumberOUT OUTPUT'
EXEC sp_executesql #SQLCMD, N'#DocNumberOUT INT OUTPUT', #DocNumberOUT OUTPUT
SELECT #DocNumberOUT
I am trying to call a scalar function on a linked server but I am having a little trouble setting it up. I am hoping to set it up as a function on my server.
Below is the best I came up with.
I am trying to wrap an openquery statement within the function on my server. However, the query works by itself by I am not able to return the results without causing an error.
USE POWERVIEW
GO
ALTER FUNCTION DBO.FN_VAR_DUMPNAME (#DUMPLOC NVARCHAR(40))
RETURNS NVARCHAR(40)
AS
BEGIN
--DECLARE #DUMPLOC NVARCHAR(40)='D11'
DECLARE #sql nvarchar(800)
DECLARE #param Nvarchar(20)= #DUMPLOC
DECLARE #retval NVARCHAR(40)
DECLARE #ParmDefinition nvarchar(500)=N'#retvalOUT NVARCHAR(40) OUTPUT'
DECLARE #innersql nvarchar(400)
SET #innersql = 'SELECT POWERVIEW.DBO.FN_VAR_DUMPNAME('''+''''+#param +''''+''')'
SET #sql = 'select * from openquery(MINESQLSERVER,'''+ #innersql +''' )'
***RETURN EXEC sp_executesql #sql --This line does not work***
END
This is too long for a comment.
SQL Server does not allow functions to call dynamic SQL. Hence you cannot do what you want.
You have other problems as well:
return exec is not something I've every seen before.
exec returns an integer.
The function returns a string.
You will need to solve your problem using some other method -- a stored procedure comes to mind.
This is part of my procedure to return #v_buffer variable.
Problem is that, the size of file i want to upload is greater than 8000 bytes. That's why i need to use varbinary(max) type.
But sp_oamethod read returns me an error.
Is someone know hot to use sp_oamethod to solve my problem?
declare #returnCode int
declare #v_file int
declare #v_buffer varbinary(max)
declare #v_fullpath nvarchar(400) --pdf file phusical location
exec #returncode = sp_oacreate 'adodb.stream', #v_file out
exec #returncode = sp_oamethod #v_file, 'open'
exec #returncode = sp_oasetproperty #v_file, 'type', 1
exec #returncode = sp_oasetproperty #v_file, 'loadfromfile', #v_fullpath
exec #returnCode = sp_oamethod #v_file, 'read', #v_buffer out, -1
if #returncode <> 0
begin
exec sp_oageterrorinfo #v_file
end
exec #returnCode = sp_OAMethod #v_file, 'Close'
exec #returnCode = sp_OADestroy #v_file
Error message returned by sp_oageterrorinfo:
0x8004271A, ODSOLE Extended Procedure, Error in srv_convert.
Please do not use the OLE Automation stored procedures (i.e. sp_OA* ) as they have been deprecated since SQL Server 2005 was released. What you are trying to do is rather simple with SQLCLR (i.e. .NET-based objects that exist within SQL Server). You can create a scalar function to accept a filepath and return its bytes using the File.ReadAllBytes method. Return that byte[] via the SqlBytes type.
You will need to set your Assembly to PERMISSION_SET = EXTERNAL_ACCESS. In order to accomplish that, please do not set the database to TRUSTWORTHY ON as that is an unnecessary security risk. Instead, sign the Assembly (using a password), then create an Asymmetric Key in the master Database from the DLL, then create a Login from that Key, and finally grant the Login the EXTERNAL ACCESS ASSEMBLY permission.
For a lot more information on working with SQLCLR, including many examples, please see the series of articles I am writing on this topic on SQL Server Central: Stairway to SQLCLR (that site does require free registration in order to read their content).
Or, if you don't want to deal with any coding, I created a library of over 270 functions and stored procedures called SQL#. There are several file system related functions, though none of them are available in the Free version. Still, the one that would help here is called: File_GetFileBinary.
If you try to pass a string that is greater than 4000 characters but less than or equal to 8000 characters in length to the sp_OASetProperty or to the sp_OAMethod OLE Automation extended stored procedure, the input string is silently truncated to 4000 characters before it is passed to the object and no error is returned.
If you try to set a property to a string that is greater than 8000 characters through the sp_OASetProperty OLE Automation extended stored procedure, or if you try to pass an input parameter to the sp_OAMethod OLE Automation extended stored procedure that is longer than 8000 characters, you receive the following error message:
hr Source Description
---------- ---------------------------- --------------------------
0x8004271A ODSOLE Extended Procedure Error in srv_convert.
https://support.microsoft.com/en-us/kb/325492
If someone had same problem, i have done it like this:
In my procedure i create temp #IMG table:
create table #IMG (FileID2 nvarchar(50), img image)
If the file size is greater than 8k, i split it to parts in size 8000 and update #IMG:
exec #returnCode = sp_oamethod #v_file, 'read', #v_buffer out, 8000
update #IMG set img = #v_buffer
SELECT #ptrval = TEXTPTR(Img) FROM #IMG WHERE FileID2 = #v_FileID2
--file split section
select #v_Blocks = #v_FileSize/8000+1
if #v_Blocks = 1
begin
WRITETEXT #IMG.Img #ptrval #v_buffer
end
else
begin
WRITETEXT #IMG.Img #ptrval #v_buffer
set #j=#v_blocks-1
while #j>0
begin
exec #returnCode = sp_oamethod #v_file, 'read', #v_buffer out , 8000
set #i=(select DATALENGTH(Img) from #IMG WHERE FileID2= #v_FileID2)
UPDATETEXT #IMG.Img #ptrval #i 0 #v_buffer
set #j=#j-1
end
end
You could use the same workaround as described at 0x8004271A ODSOLE Extended Procedure Error in srv_convert.
In your case, the line
exec #returnCode = sp_oamethod #v_file, 'read', #v_buffer out, -1
should be replaced by
Create table #tmp(dt varbinary(max))
insert into #tmp
exec #hr = sp_oamethod #v_file, 'read', #mode = -1
Select dt from #tmp -- single column/single row.
Drop Table #tmp -- clean up
Caution: this code wasn't tested. However the following code works fine for 32KB xml output:
Create table #tmp(dt xml)
insert into #tmp
exec #hr = sp_OAGetProperty #obj, 'responseXML.XML'
/*
Here is the trick: inserting from the returned result set, i.e.
`insert into <table>(<columns>) select <columns>`
*/
Select dt from #tmp -- single column/single row.
Drop Table #tmp -- clean up
responseXML.XML returns the whole xml document after calling MSXML2.ServerXMLHttp.send. The trick works according to section Result Sets of sp_OAMethod.
When the table variable type is available, the code can be even shorter:
DECLARE #xml(val xml);
insert into #xml
exec #hr = sp_OAGetProperty #obj, 'responseXML.XML'
Select * from #xml; -- just to see the output
I.e. there is no need to clean up.
I received the same issue. Apparently, you cannot use sp_OAMethod with a VARBINARY(MAX) variable.
Try changing: declare #v_buffer varbinary(max)
to declare #v_buffer varbinary(8000).
Good luck!
I'm currently tasked with reading some data that stored in a flat file into my database and run reports against it. The one problem I'm running into is checking to see if a file actually exists. Is there a simple function to check if the file exists?
Thanks!
Just googling I found this at SQL DBA and this at MS SQL tips.
You are doing ETL in a stored procedure?!! I don't think you should, just because you can.
I recommend you use use SSIS for this. Doing ETL in Stored Proc or TSQL is not a recommended practice, in fact, it is frequently used as an example of what not to do.
I believe you can do something like this:
DECLARE #Path varchar(128) ,
#FileName varchar(128)
SET #Path = 'C:\'
SET #FileName = 'FILE_NAME.EXT'
DECLARE #objFSys int
DECLARE #i int
DECLARE #File varchar(1000)
SET #File = #Path + #FileName
EXEC sp_OACreate 'Scripting.FileSystemObject', #objFSys out
EXEC sp_OAMethod #objFSys, 'FileExists', #i out, #File
IF #i = 1
PRINT 'file exists'
ELSE
PRINT 'file does not exists'
EXEC sp_OADestroy #objFSys
This article goes over this method and a couple others.