I have this package - it simple moves data out a Visual FoxPro Table and unpivots it into a SQLServer 2008 table. It works beautifully in BIDS. It's basically a Script Task with code to run through the table.
Normally it would have two R/W parameters (one of which is m_filename) - but I have also put some default values in it when I constructed the package - so hopefully it runs on its own. It doesn't have connection manager elements - as they have been hardcoded.
Dim outputConnAsNew OleDbConnection("Provider=SQLNCLI10;Data Source=localhost;Initial Catalog=Reporting;User ID=xxxxxx;Password=xxxxxx")
Dim inputConnAsNew OleDbConnection("Provider=VFPOLEDB.1;Data source="& Dts.Variables("m_filename").Value &";Extended Properties=dBase III;")
I want to call it from a .NET web application through a Stored Procedure.
1. Loaded as Agent Job (looks like the right syntax…
When I start the job then the message comes up that it cannot set the m_filename – how can I resolve this?
When this package runs it actually works as 32-bit (in title!) So we simply need to get the variables set!
Decided to remove the need to load the m_filename etc. so no parameters were loaded and the package validation returned DTSER_SUCCESS (0). (So it would use the default values). But no records loaded!
2. Direct in a Stored Procedure
In a stored procedure we use the following command which I simple run and what is generated is the result set with errors below.
DECLARE @result varchar(500)
EXEC @result = master..xp_cmdshell 'dtexec /x86 /f "c:\cube\VFPImport.dtsx" /SET \package.Variables[User::m_filename].Value;"C:\DBFDATA\TEST_REPORT.DBF"
/SET \package.Variables[User::m_version].Value;"VT7777"'
When I run this I get the error which suggests that VFPOLEDB.1 is not registered – and yet it was registered to run when in BIDS on the same machine. How do I force the
registration in SQLServer - that can work?
However note that even though I used the /X86 switch to make it 32 bit mode – the utility seems to be the 64bit utility in the debug title! So the switch doesn’t work! They say that there is a different DTEXEC: one for 32 bit and one for 64bit. I think this
is the reason that the process if failing to find the VFPOLEDB.1. If it found it – we still have to get over the fact that we cannot set the parameter values.
When I took the parameters out and just run the package with defaults it still came out with the same problem
3. Loading into SQLServerIntegration Services section of SQLServer (not SQLAgent)
By starting up Integration Services – I was also able to load the package – but again the same no reading m_filename error. Could this be a privilege thing do you think?
This time I ran it without the parameters so using default.
It worked perfectly.
Then I checked and the records were in place! So leaving 8702 records for 110 records in the system. But clearly I am going to have problems running this unless I can do it properly through a SP? What seems to be wrong?
The code works in BID really well - which is wonderful - as I hear so much about problems working with VFPOLEDB.1
Steve