I have a bad situation I'm trying to work through and would appreciate your help. We have a legacy .NET application that initiates a stored procedure call that is exceeding the default command timeout threshold. I know how to change the command timeout threshold in code (that's easy) - the problem is that we don't have the source code for this legacy application (trust me, no one's more upset about this than I).
We're working on optimizing the Stored Procedure, but we're facing some blockers. Namely, the database which the Stored Procedure runs against is a vendor database and they've said they can't add some indexes that would help. We're also facing an issue where the vendor's database has grown dramatically over the last few years and the size appears to be contributing to the problem.
Previous to our optimization efforts, the stored procedure was taking minutes to complete. We've now got it down to about 36 seconds, but we're not sure if we can get it below the default command timeout of 30 seconds.
I've read that there's no way to change the command timeout in the connection string, but I was wondering if any of you fabulous people had any ideas on how to change the command timeout outside of code.
Thanks!
You can use ildasm to alter what will get executed directly in the .net dll. e.g. see top answer in:
dotnet dll decompile and change the code
There's a bit of a learning curve, but it is possible.
Or could try something like DnSpy https://github.com/dnSpy/dnSpy , which looks promising.
Some discussion of DnSpy at:
Modify Compiled .Net Exe
Related
Windows 7 64-bit.
OracleXE installed since February.
Oracle instantclient 11.2 installed as well, so I have both c:\oracle\ and c:\oraclexe.
I use SQLPlus every day.
It's location is C:\oraclexe\app\oracle\product\11.2.0\server\bin\sqlplus.exe
I have not changed my environment variables during this 6 month period.
Yet, suddenly, SQLPlus stopped working. Permanently. Even after reboots:
Error 6 initializing SQL*Plus
SP2-0667: Message file sp1<lang>.msb not found
SP2-0750: You may need to set ORACLE_HOME to your Oracle software directory
Now there are TONS AND TONS of pages of people discussing this exact problem. Every single solution involves setting ORACLE_HOME. None of these fix my problems. In fact, ORACLE_HOME was not an environment variable at any point between February and today!
These pages are all repeats of each other, and I've satisfied every solution condition on every one of those pages to no avail. And they are almost wholly about people who JUST installed Oracle.
But what about me? My install was perfect for 6 months, and just rotted away one day without me changing anything.
1) I've done the set ORACLE_HOME=c:\oraclexe\app\oracle\product\11.2.0\server\ to no avail. I've also taken about 10 shots in the dark with setting it to different levels in that path (like c:\oraclexe), but everything I've read suggestions it should point to the server folder.
2) I know it's not a path problem because I have no problem running SQLPlus. The error is generated by SQLPlus.
3) I've tried set LANG=us {even though I didn't need this at any point in the past}
4) I've even tried set NLS_LANG=American_America.we8iso8859p15 to no avail.
5) Yes, sp1us.msb is indeed at: C:\oraclexe\app\oracle\product\11.2.0\server\sqlplus\mesg\sp1us.msb
6) I've even used Sysinternals Procmon to see where SQLPlus.exe is looking. It's a lot of output to wade through and I'm not too familiar with the tool, but it seems to indicate that SQLPlus is looking for the file... Right where it is! So why can't it find it?
7) I don't think it's file permissions. Ran fine for 6 months. I've ensured that I own the files via takeown and icalcs -- but only after the problems started.
8) It's not antivirus.
Twice I've mucked around and managed to get it run correctly, and both times it only ran once and stopped working correctly. So I could never verify a step that consistently got it to work. It makes no sense to me that it would run once, but not twice - It's almost as if SQLPlus itself is changing the environment to prevent SQLPlus from working.
I found the problem!
I was setting an environment varaible SQLPLUS in my own script.
I was using it for non-Oracle-specific purposes.
I guess I collided with a variable they wanted to use.
Strangely, I've been using this script (a sqlplus.bat that forks to different sqlplus behavior) for 2 years, and my choice in temporary environment variable only presented a problem this week.
Very odd!
In my SSIS package, I have a script task in addition to other tasks. When I put a debug point within the script task and run the package( on the whole), ideally, it is supposed to hit the breakpoint. but it now only opens a new VS window, shuts it after few seconds and a green tick is displayed over the task.
I tried setting the the Run64BitRuntime flag to false and also editted and saved the script task again. The issue persists. Any pointers on this ?
I have VS 2010 BI and the machine is 64 bit Windows Server R2
Yes, break points do work in script task. But if that was a script component, then it wouldn't have worked. Any way, if you have a script task, the reason it might not be working is that it may be using the 64 bit runtime. Try running it in the 32 bit runtime.
Also, make sure that the place at which you have hit the breakpoint is actually reachable. If there are some case statements or if conditions, possibilities are that the line of code is actually missed.
Surely debug is allowed for script task. Couple of point to remember
1. Run the package in 32 bit
2.wherever u set up debug pointer... code should be rechable
3.debug only allowed for 1 script task. Ssis engine can only show you debugging only for 1 script task. If you have 2 script task then ssis will open debugging only for first script task.. suggesting you put de bugging only to one script task
I ran into this as well and found the script task had been set to optimize code even for debug mode.
See more detail here
Let me state upfront that I truly appreciate any assistance on this issue.
I have a C# (2.0) application. This is relatively simple application that executes stored procedures based on an XML file that is passed as a command line parameter.
We use it as a tool to call different stored procedures. This application does some logging and for the most part works very well.
The application reads the stored procedure name and parameters from an XML file. It sets up a connection string and SQL Command object (System.Data.SqlClient.SqlCommand).
Then it runs the stored procedure with the ExecuteReader method.
Unfortunately on a handful of occasions this application has generated the following error:
“Application popup: StoredProcLauncher.exe - Application Error : The instruction
at "0x7c82c912" referenced memory at "0x00000000". The memory could not be "read”
This error has appeared on multiple servers so it must be a code issue.
It seems that when our production server rolls a certain number it belches out this memory error.
The problem is I don’t see this issue on development. I can’t replicate it so I’m stuck.
Is there any way to simulate this error. Can I fill up the memory on my local PC somehow to attempt to replicate this error?
Does anyone know some common coding issues that might result in an error like this?
Does anyone have some rope I can borrow?
One way to do this is to wrap the offending code in a try catch block and writing the stack trace and error message to the windows application event log, text file, email, etc.
This will give you some line numbers and additional information.
Also note, you may need to deploy this in debug mode or at least copy the .pdb file with the application exe/dll so it can get the debug symbols. Can't remember off the top of my head how that works, but I think when you deploy in release mode you may loose some valuable debug information.
The instruction at "0x7c82c912" referenced memory at "0x00000000"
This is an access violation:
An access violation occurs in unmanaged or unsafe code when the code attempts to read or write to memory that has not been allocated, or to which it does not have access. This usually occurs because a pointer has a bad value.
Why does your program have unmanaged/unsafe code? For doing what you described it needs no native code.
Alas, the code crashes and now is not the time to wonder how is ending up calling native code. To solve the issue you're going to have to catch a dump and analyze the dump. See Capturing Application Crash Dumps. There are tools that specialize in this, like breakpad. there are also services that can help you collect and track crashes generated from your app, like crittercism.com or AirBrake. I even created one for myself and made it public bugcollect.com.
I'm trying to debug an issue that happens on service startup. Trying to attach while things are running is failing, windbg times out with an error about a link lock. I think that the error occurs before I have a chance to attach. A sleep might let me attach, but is there a more elegant solution?
I'd like to start up the debugger first thing as the service starts. C# has a Debugger.Launch() method to start a debugger at runtime. Is there an equivalent C call that can be used without .net? Something I could just drop in the start routine.
I can't call DebugBreak because at the time the service has started I'm not under a debugger.
Sleep is certainly a viable approach. It's crude yet effective. Somewhat less crude is to use a good logging framework to output diagnostics. With a sufficiently capable logging framework this can be very effective.
I was searching for connecting to database from C program. But I thought the ODBC connections, logon and all need some libraries. Also I am having a minimal compiler like Tiny C Compiler which is very fast. I do not want to use any ODBC logic etc which is needed to connect and query the database.
So I am using a method which is as follows.
I use a bteq script (teradata) which will have login, query, logoff commands in that. (FYI bteq is a command line database utility. You can use it similar to mysql.exe in command prompt by going to the path of the exe. You can replace bteq with mysql.exe etc). And I use
system("bteq <myscript.txt >out.txt");
myscript.txt will be like the following..
.logon boxname/user,password;
select date;
.logoff;
The above script will logon to the database and query date (you can change the query and write script according to your database engine and your needs) and give output into out.txt.
Now I will parse the out.txt for the row X column I want using fgetc,fscanf or fgets.
And use the data for checking and send a mail using PHP on any server
system("c:/server/php/php.exe sendmail.php");. We can do the same for many a database engines like mysql, .. etc through a simple C program.
Now my question is Is there any flaw in the above method.
If it is then how can I overcome it. I am asking this question because I think this method is unconventional. Please give your opinions on this method. I don't bother about time needed for execution, RAM used, performance issues etc. I know system() function is time consuming which is not my concern anyway. I also developed specific functions to access query results (similar to accessing a flat file). Please tell me if you have any improvements to this method. If you get to know of any flaws in this please let me know. All kinds of suggestions are welcome.
My environment is : teradata bteq on windows with Tiny C Compiler
This is a perfectly fine way to access an external database, as long as your needs are simple. If you already know about the performance and memory implications of doing this, then there's not much more to say.
The method is fine: it's great to decouple the db subsystem and the parser subsystem by implementing them in an appropriate language.
There's just this tiny little thing - but I may be mistaken because I'm not familiar with bteq: the program will need a bteq script installed in the execution folder; this script will contain username and password. If those aren't encripted in some way, there might be a security flaw.
I wouldn't recommend this if your calling code is running setuid or setgid, but in that case you could use one of the exec() functions instead. (There are a few other considerations you may wish to take into account, all detailed in man 3 system.)