I have a cleanup task for cleaning out old backups. It hasn't been running. Well, it's been starting, but failing every time.
The log file says: "Executed as user: [omitted]. Microsoft (R) SQL Server Execute Package Utility Version 10.50.2500.0 for 64-bit Copyright (C) Microsoft Corporation 2010. All rights reserved. Started: 3:00:00 AM Progress: 2015-02-19 03:00:04.67 Source: {1B09CDD3-A5E1-4C82-AEC6-4E36DD2BA8DC} Executing query "DECLARE #Guid UNIQUEIDENTIFIER EXECUTE msdb..sp...".: 100% complete End Progress DTExec: The package execution returned DTSER_FAILURE (1). Started: 3:00:00 AM Finished: 3:00:05 AM Elapsed: 4.594 seconds. The package execution failed. The step failed."
When I look at the task, I notice a red x on it that says "No connection manager specified" or " There were errors during task validation." I can only assume this is the reason.
My other ones are fine.
Someone suggested this to me "Have you opened the DTSX package to see what is in there for a connection. It sounds like nothing is in there for whatever reason. "
To which, I answered "I don't know what that is. But, I did open the properties and Connection is blank. All the others say "Local Server Connection".
I wonder if I need to be on the server to make changes. I usually manage things from my own PC. In the past I thought I only had to go to the server to create new plans, not change existing ones. And I think this one was working fine until I changed the "Delete files older than" setting. "
I'd love some help on this.
Well, I fixed it myself. I am still not totally sure why this happened; maybe someone can shed some light on that. But, I open up the step and the Connection part was blank. I entered in all the credentials and changed the schedule to now to test and my files cleaned up.
Related
I was running a trace on an application today and saw this for the first time ever, in the text data of the trace:
exec #spDMF1F848FB98D743F69BA4AF02A7C05927
Can't seem to find anything online anywhere. I am guessing that it is some kind of temp procedure that the application built in background, but that is a complete guess and never have heard that was even possible.
Running SQL Server 2005, SQL Server Management Studio v15.0.18384.0
Anyone familiar with anything similar?
Progress application terminated during execution. Here is the protrace:
Exception code: C0000005 ACCESS_VIOLATION
Fault address: 101DA9BF 01:001D99BF C:\Ultra\dlc91e\bin\prow32.dll
How to find what program caused this issue? Is there any way to debug and find the problematic code?
If it was a 4gl session that crashed there should be a "procore" or a "protrace" file in the working directory of the session that crashed. It might also be in the temp directory (specified with the -T startup parameter).
If you can find the protrace file it has a 4gl stack trace which ought to tell you where the problem originated.
Some notes here:
9.1e is truly ancient. But still Progress has a history of supporting older versions a long time. It's actually set to be "retired" October 2015.
So if you have an active license you shouldn't hesitate to contact support.
There's also the knowledgebase to search. I found this that might be something similar. First of all you should think of all things that have changed since the system worked (file system layouts, installation of software like antivirus and firewalls, operating system upgrades, security changes etc etc).
Knowledge base home: http://knowledgebase.progress.com/.
I never use the internal search, I always Google with:
site:knowledgebase.progress.com
I'm currently creating a package for SCCM that is wrapped using PowerShell. My package will return 3010 - reboot required when the script is finished. But upon checking the execution history of the machine where I assigned the package, 3010 exit code was recognized as Exit Code Failure. I've been searching many knowledge base site (MSDN, TechNet, etc) but I could not find anything that can enlighten me with this behavior I got for the SCCM package.
So far as I know there is an exit code mapping but from what I saw in SCCM 2012 this feature is only available for applications in SCCM. Is there anyone knows how we will able to make SCCM recognize the exit code of packages in the same way like applications?
Thank you.
No you can not set custom exit code values for Packages. In the properties of the program you can set the 'After running' and have Config Manager control the restart. That should give the user a notification that a restart is required.
After upgrade our IBM System i (aka i5/OS or AS/400) from V5R4 to V7R1, one of our applications that connect to DB2 using ODBC fails with the following error:
Error Code: 69899
SQLSTATE: S1000
[IBM] [System i Access ODBC Driver] [DB2 for i5/OS] PWS0005
Error occurred in the database host server code.
The symptoms are:
In a While / Wend loop a CURSOR is declared, then opens, do fetch(s) and close.
If at any iteration the cursor does not retrieve any rows, in the following iteration the error occurs after declaring the cursor (with a different SQL query) when you try to open it.
First we updated the ODBC driver to the latest version available, but the problem persists.
Because we needed an urgent solution, I solved the problem by making a pre-select to determine if the cursor will return rows, otherwise skip that iteration, this solves the problem for now but does not seem a very elegant solution.
Any idea how to get more information about the error that occurs on the host?
Thank you very much in advance.
Generally speaking, if an error occurs in the server side code, you should call IBM support and report it. They'll ask if you're on the latest cume and probably the latest database group PTFs.
The server runs the ODBC connexion in a job called QZDASOINIT. Since there are probably many connexions to the system, there are probably many QZDASOINIT jobs. To find yours, go to a terminal session and WRKOBJLCK MYPROFILE *USRPRF. You'll be presented with a list of jobs running with your user profile. At least one of them will be the QZDASOINIT job you're looking for. Use option 5 to look at the job, then option 10 to see the job log. Press F10 to see the detailed messages and F18 to go to the bottom (most recent) entries.
If the error was so severe that the server job terminated abnormally, there won't be a lock on your user profile. Instead, go to the spooled job log by using WRKSPLF.
IBM have been logging some SQL internal errors since V5R4. select * from qrecovery.qsq901s; to see any SQLCODE -901 errors.
Make sure that you have installed the latest fix pack for the latest version of System I Access
I've had this error before and it was caused by a syntax error in the connection string. It was a setting that was insignificant in older versions of the OS and more significant in newer versions, but did not cause the connection itself to fail so it was hard to track down.
For example: Port Number:8471 had a spelling mistake and was Porte Number:8471 hard to spot but once found, it fixed the problem for me. Basically everything past this part of the connection got ignored.
Wanted to add another solution to this problem. The SQL Packages that exist on your system get corrupted after/and or during upgrades. You MUST delete these packages after an upgrade. This will get rid of the old packages and will allow the system to recreate the packages at the new OS version level. When deleting SQL packages some connections/jobs may have locks on those packages so you might have to shut host services down. Use the DLTSQLPKG command to do the delete. In v7r2 and higher there are some additional steps to do as IBM changed somethings when it comes to packages you can find the info here http://www-01.ibm.com/support/docview.wss?uid=nas8N1015556
Or tell your ODBC/JDBC/.Net Data adapter/provider to not use packages. This is probably less desirable as there are performance benefits to packages.
I am deploying project with developer-targeted setup using Inno Setup. I've wrote some code to make some actions that are a bit too custom for the original Inno Setup.
One of such actions was connecting to and running SQL files, thanks to StackOverflow users I've found some code for doing so. The problem is that whenever I try deploying the project on a new Windows Server 2008 machine (x86), I'm getting such cryptic error on every sql command apart from the first one:
"Not enough storage space is available to complete this operation ProgID: ADODB.Connection"
So. The first command fires and works, next stop with error. If I'd run the code again, some of the commands might work, but at some point, the installer would hung. The problem does not exists on windows XP I am writing it on.
I use the code linked above for every SQL command I run (new ole object ADODB.Connection, new command, execute... end) - I don't make the second query for results of insert (as it's there just for showing purpose).
Any thoughts what can be happening here or how can I make a workaround?