I have created an SSIS-Package, which is supposed to import Data from Flatfiles (txt. Files) into a Database.
When I execute the package via Visual Studio (Enterprise, 2015), there are no problems and everything works just fine.
The problem occurs when I deploy the package into SSMS (Express, 2014). When I execute the package from SSMS, I get an Error (no idea if there is an Error Code or where to find it) concerning the property "CreationName". SSMS doesn't seem to give me any other information.
In the package are 5 scripts, which all do the same but with different flatfiles.
They all get this CreationName Error.
Has anyone any idea on how to fix it or the source of the problem?
i solved the problem, but it had nothing to do with the creationname apparently - i made some wrong settings in my sql agent + i made it work by deplying it from my hard drive instead of the virtual drive. I also had a typo in one of the scripts :x Idk why it had problems with the virtual drive though; maybe it was an authentication problem. Still THANK YOU ALL SO MUCH! You guys kinda brought me there :)
I don't understand what's written on the attached image, but I would disable 4 out of 5 components then run through the job. If there's no error than disable 3 out of 5 and run it again...you get the point. Obviously this has to be done in a non-prod environment. I believe that will help you narrow down the problem within your package. Maybe you can debug from thereon?
Related
So I started with the Access contact database template and have been building up from there. There is a functionality in which by clicking on the ID number in the Contact List, it should call up the form to edit the details. I have made no changes to this code, and have even tried recopying it from the template from scratch.
However I am getting the error "A problem occurred while Microsoft Access was communicating with the OLE server or ActiveX Control." It is telling me to restart the OLE server and try the operation again.
I have an old version of the database saved, and it runs fine over there. It just is something within my code here.
Any guidance would be appreciated.
All of solutions I found online was not working for me.
Found that only rebuilding damaged form from scratch help me to solve this issue.
W10, Office 2016.
I have ran into this error three times in my database. Each time to fix it I simply just open a new blank project and import everything from your old project into your new project.
This might sound like a large undertaking basically you just go into the new project and select "Import Access Database". Then just run through the wizard selecting everything in your current database. Click okay and let it run for a few minutes.
This has fixed it for me every time I have run into your error. I suspect it is just something to do with corruption.
My programs also run into this error sometimes.
I have recently noticed that the error most often occurs on UNBOUND forms (forms without a RECORDSOURCE).
What I have done most recently for these forms is the following:
Add "some" table (I usually take a Config table with just one record) as the RecordSource.
Compile the program code (this usually goes well, even before the fix!).
Save the form
Open the form. This should work fine now!
Remove the form's RecordSource, recompile and save again.
The form should still work fine!
We have developed Custom SSIS components that integrates with an online REST API (Shopify to be precise) and these components work fine in BIDS and every single time too. However, when I create a SQL Server Agent job for the SSIS package that uses the components, some of the components don’t work, there is no error, just never hits the Pre Execute. The components that don’t work call the REST API and set specific TAGS on some orders, they do so using a JSON. The SQL Server agent is running on the same machine (my own) and it's executing the same SSIS package that works in BIDS. There are no errors and the SQL Server JOB reports success.
My machine is a 64 bit setup, so obviously the Agent will be running in 64bit so there may be issues there.
This is what I have tried already
Changed the SQL Server Agent user to eliminate the issue being a proxy/user issue.
Changed the setting for the step to use 32bit runtime (Ticked “Use 32 bit runtime”)
I have tried compiling my code using Any CPU x86 x64 .. with different results but none of them work etc
The installation project (which is part of the solution) is a WIX Toolset project which can only compile using x86 which I don’t think I can change.
Logged where it is getting to a log file.
I think it might be 32bit/64bit issue but maybe wrong. The log file shows the following
When called from BIDS (works)
• Validate (code running as 32bit)
• Validate (code running as 32bit)
• Hits Pre Execute and it all works thereafter
When called from SQL Server Agent (doesn’t work)
• Validate (code running as 32bit)
• Validate (code running as 64bit)
• Never hits the Pre Execute
Like I said, I suspect it being a 64bit issue but maybe wrong.
Hi guys and sorry for not posting the answer.
First of all thank you for all your help, especially Nick McDermaid as you kept trying and trying. I really appreciated your pointers and without them I wouldn't have solved it ( kind of solved it :o) ).
My SSIS Custom components only work when I have a "Success path" coming out of them. This was only an issue on this particular occasion because it was the last component called in my Data Flow.
This could be down to a bug in my SSIS Custom Component but I am sure I have had this issue with other components in the past (I think it might have been the 'Send Mail Task').
If anyone comes across this issue again then I would love to hear from them.
I'm currently fire fighting at work so hadn't had a chance to look at the SSIS Custom Components again.
Once again, thanks for the help I received.
I realize this question is very old, but I thought I'd put in my answer. I just ran into this very issue and the answer was that the SSIS engine didn't see the custom component doing anything so it removed the component at runtime. I was able to get around this by changing the RunInOptimizedMode property of the Control Flow object to False. After this I was able to run the SSIS package as a SQL Agent job.
If you run the package through dtexec.exe as bilinkc suggested in your comments, it should give you messages that make it obvious if this is occurring.
i have a package which runs for about 6 hours. I looked at it every once in a while, it was going well. In the morning i saw that every task was green and it said "Execution completed", but when i clicked on it to stop the process, i got this message - "cannot detach from one or more processes. Would you like to terminate them instead?" So i chose yes.
The question is is it safe to continue with my work? Did the termination affect my DB somehow?
Again, all the tasks where already completed.
Will appreciate a quick response as i don't know whether to proceed or execute the package again..
thank you!
I'm using SQL Server 2005 and visual studio 2005
This looks like a problem with the designerm, not with the package itself, so I would say you can deatach
Quick question, are you using checkpoints on a package that big?
If not, I suggest you to use it. If you dont know what it is, its basically a functionality to allow your package to run from the point of failure. So, if you pacakge fails at 5:30, you can rerun it from the last checkpoint taking just an hour opposed as runnig everything again
I too had the same problem, I have increased the buffer size from 10000 to 100000 that resolved the issue. Please try this.
So I'm working with SSRS (SQL Server 2005), which some of our applications use to generate downloads. The problem with it, though, is that the Reports website that is used to manage it seems to crash randomly. I haven't yet figured out a rhyme or reason to it - only that it will suddenly bust out with a 'Specified cast is not valid' exception and any further attempts to do anything will fail with
The item '/' cannot be found (RsItemNotFound)
Is there a place I can start looking to help me debug this issue? Are there logs that might have more in-depth information than the useless error messages I'm getting?
Is there anything in the standard event logs? You'll probably find lots of logs to go through in (C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\LogFiles)...that's the default path at least.
we have a web app at where i work that occasinally, after it's been left alone for a while, has to "recompile" and will take a few seconds before it'll show a page. i've noticed that ssrs does this at times, and it might or might not be causing your problem.
you could test this by setting up an instance of ssrs on your local machine (that you know no one will get on) and running your downloads against that.
also, check and make sure no one is turning anything off or doing any backups when you are doing the downloads.
I have a question for all of you and please any ideas are welcome. We have alot of MSAccess database projects in our repository on which developers work and do there tests in Dev Envoirment on there own. As you all know compiling a databse project is itself a wrong statement, cause you actually need to test your scritps and reports and everything else againt a databse. SO what can we do in TFS build script in case of MSAccess Projects , i am out of ideas. Anybody who has come across this issue and have done something about it, i would really appriciate if you share.
Any example or link which will explain how to go about it would be even more better. Please understand that its an MS Access Projects.
Thanks
BOB
Compiling is not entirely an wrong statement.
In the VBA side, there is a an option under the Debug menu called Compile (I don't believe its truly a compile like in C, but it is pre-parsing your code, etc.). This combined with building an MDE in the GUI side equates to compiling.
Typically, when working with the VBA I'll run the Compile frequently to make sure everything is syntactically correct, etc.
As far as testing goes, once you know that it compiles you still aren't done. If can compile and still be wrong. That's why you need automated test scripts. I'd consider a little script/form within the MDB that you can run manually to open and close all the Reports are concerned about and exercise the code. Actual form functionality would be more tricky to automate, but could be done as well.