I've been using SSMS, SQL Server Profiler and SQL Operations Studio for a while now without issue. However, when some query text (TextData column) was getting truncated in the profiler, I decide to increase the SSMS "XML Data" size to "5 MB". Now all three applications hang at different spots.
SSMS and SOS hang when scripting table as a SELECT.
SQL Profiler hangs after moving past the connection dialog.
In event viewer, I see this error:
Application: ioc.exe
Framework Version: v4.0.30319
Description: The
process was terminated due to an unhandled exception. Exception Info:
System.AccessViolationException
It's also important to note, it is definitely not the case that the trace window/connection dialog/etc. is rendering off screen. Simply, the applications are hanging due to an unhandled exception.
Restoring Query Results options to default didn't work.
Relaunching SSMS/SQL Server Profiler/Sql Operations Studio didn't work.
Rebooting didn't work.
Running applications as Administrator didn't work.
I ended up pointing the connection dialog to another database to see if that made a difference and I was able to connect. This seems to have jarred something loose; I had to do this for all three applications separately, each time performing the task that hung on prior attempts on a different server fixed the problem. Though I wish I knew what was happening under the covers, I wasn't able to find any resources describing this same issue.
Once I pointed back to the original database I was able to launch each application successfully.
UPDATE - I later found that ioc.exe is Intel's Lenovo bloatware (Intel Online Connect). A security suite, which I promptly uninstalled.
Related
I have a program written in VB due to the simplicity and GUI when using Visual Studio 2010 as my IDE and compiler. In this program I built a "ticketing" system where approximately 40 users in my center have the authority to submit tickets to my coworkers and I for IT or Facilities assistance.
This system uses an access database on the local server using SQL as the language. The problem is that we have rare occurrences where two users are trying to write a "ticket" at the same time to the database or pull a report of the data at the same time from the database and it crashes on one of users. I use a "try, catch, finally" block to avoid the "unhandled exception error" and have the program setup that should an "unhandled exception error" occur that it closes automatically. The other concern is that once this collision has occurred, the user can no longer read/write to the database through the program until they restart their computer.
With all that in mind, my question is as follows, is there a 100% way to prevent these collisions from occurring (like checking if the database is in use before reading/writing) and if not is there a way to avoid them being locked out of the database until restarting their computer?
Since this post I have swapped to a virtual MySQL database server to run these at much better speeds. The issue I was having however, was resolved by clearing the pool. Since at the time I was using OLEDB I used the command:
OLEDBConnection.ReleaseObjectPool()
and it prevented any more of these computers being locked to where they had to restart the computer as well as help prevent collisions.
Assuming you are using OLEDB, you can try using Transactions, which are simple to implement as explained in the Developer Network article entitled OleDbConnection.BeginTransaction Method.
I must admit I do not understand the IsolationLevel settings, but try omitting it or using the default shown in the example before trying the other available cryptic ones.
As Tony suggests, converting to SQL-Server is a much more robust (long-term) solution that will ensure data integrity, especially if you plan to add more users. MS has a free migration tool that does an excellent job, even on queries. As for data integrity, see the last paragraph in the Microsoft Support article: Using Microsoft Jet with IIS
Environment: SQL Server 2008 SP3 - using SSMS2008 (local or remote) and SSMS2012 (remote)
Something happened with our SQL Server instance recently. Nobody is able to create a new database through an SSMS (SQL Server Management Studio) interface. Neither SSMS for 2008, or SSMS for 2012.
What happens is they hang (or appear to hang). Sit and spin forever, and then the performance of the SQL instance really starts to tank while it is chewing away. CPU usage skyrockets.
Things I've noticed:
Telling it to create the MDF/LDFs on a local drive or network drive makes no difference.
We've tried disabling the anti-virus tools on both the SSMS machine and SQL instance server, with no change.
We've tried using the SSMS on the SQL instance server itself, and it also just spins. Any SSMS (we've tried three different machines) does the same thing.
If I open Windows Explorer and look at the locations I've told it to put the MDF/LDFs, they are created. I see the MDF and LDF show up.
As soon as I kill the SSMS process (because it feels like it's hanging), it does some cleanup work and the MDF/LDFs go away.
I can successfully use the CREATE DATABASE t-sql script in a query window, and it creates the databases fine, fast as can be, like one would expect.
FILESTREAM is not enabled for the server instance at all. No database uses it in the instance.
This only started happening recently - and the only thing I found with GoogleFu was a hotfix by Microsoft for SQL2008-SP2, that had to deal with microfilters and antivirii. This is SP3, so that fix is rolled into it (as well as we disabled AV on the SQL server and our local machines - to be sure).
Any suggestions or ideas? Is there some trace profile I can start up that would show me what is going on, step by step, to see where the SQL instance seems to be spinning its wheels when I try creating a database through the SSMS interface?
We have a windows 2003 server with crystal reports running on this, that ties to a sql db. Yesterday afternoon all reports that I was trying to run suddenly started freezing. I thought initially it was device specific and it was my pc and tried several other devices. Then one of my analysts noticed he couldn't run some standard Thursday reports which also froze .. etc.. Where does the error log for each of these reports write to so I can investigate the root cause?
Running slowly will not necessarily produce an error. The best thing for you to do in this situation is run the SQL used in your reports directly against SQL server from management studio, this way you have a whole host of performance monitoring options, you will also get a better feel of what the issue could be. Continue to troubleshoot different factors procedurally and you should find the issue.
I am running an instance of SQL Server Express on an old underpowered tablet PC used for a special purpose application. Periodically the SQL Server process kicks in and hammers the CPU at 100% bringing the application to a halt. (Technically, it doesn't halt, it just slows it down to the point where key processes time-out.) It will be another two or three years before the hardware is replaced so that's not an option. Is there a way to throttle SQL Server Express?
There are a few techniques to identify CPU-hogging activity on MSSQL, but since your box is completely unresponsive at the time, you have few options. Using SQL Profiler to run a background trace logging to a table or file might be your best bet.
Until very recently, you needed a paid version of MSSQL to use Profiler, however MS now includes Profiler with MSSQL Express 2012 SP1. Here's a direct download link:
http://www.microsoft.com/en-us/download/details.aspx?id=35579
(Note, you can probably install Profiler without upgrading your MSSQL server instance, if you don't want to).
If you've never used Profiler to diagnose CPU-hogging queries before, here's how I would suggest going about it:
new trace > connect to your MSSQL instace
make sure the "CPU" column is selected
make sure both the "started" and "completed" events for all the queries (Statement/Query/Batch/Procedure/etc) are checked.
Use a "column filter" to only show events where there is a value in the "CPU" column
Select a name for the trace, and a destination (table or .TRN file)
Start the trace and leave it running
After experiencing the CPU issue, once your box recovers: open the trace results, paying particular attention to the CPU column, and the date/time the 100% utilization started. Here's a link with more about using Profiler to analyze traces:
http://msdn.microsoft.com/en-us/library/ms175848.aspx
I am running Windows Server 2003 R2 Enterprise Edition SP 2
I have created an integration package in VS 2005 which extracts data from Excel and imports it into a table on SQL server 2005 running on this server.
The package runs ok in Visual Studio 2005,I did a bit of research which suggests this is due to SQL 64 bit and Windows 64b bit, however I am running 32 bit !!
Description: An OLE DB error has occurred. Error code: 0x80040154.
An OLE DB record is available. Source: "Microsoft OLE DB Service Components" H
result: 0x80040154 Description: "Class not registered".
End Error
Error: 2010-01-04 16:02:19.14
Code: 0xC00291EC
Source: Delete from ExcelDB Execute SQL Task
Description: Failed to acquire connection "Co
nnection may not be configured correctly or you may not have the right permissio
ns on this con
Please help to resolve this issue
A couple of suggestions of things you could try
It says that its failing on 'Microsoft OLE DB Service Components'. Can you identify this component, and include it in a simple C#/VB.NET project. Perform a simple test within the project code, e.g. instantiate it and call a method. Then compile this to an EXE, transfer across to your server, and run it there.
The next thing to try is to trace the fault using Process Monitor:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
This is not for the faint hearted, as you could get tens of thousands of entries, but its possible to narrow the entries down:
1) Turn trace off and clear all your entries before you start.
2) Start the trace then quickly, start your package (e.g. have a command line keyed up)
3) Stop the trace as quickly as possible once you get the errors.
With any luck you might be able to determine where exactly the failure is occurring. This tool has been invaluable in the last few months, and I've followed similar step on a number of occasions.
Good luck