The error as seen in the image is a compiler error -1073741502. I have searched SO and Google with little success. Tried to debug the process and was not able to determine what the issue is causing the error. The error has been occurring for some time and is random with no apparent pattern in the data or operation. This is also in a VB website using .net 4.0. The report RDLC has been recreated 2 times to see if the issue would be resolved but was not successful.
The only way to get the application to continue past this error once it occurs is to do an app pool reset. This is something we would like to avoid doing for obvious reasons.
Any help and suggestions are appreicated.
I have a form with a button which opens a new form to add a new record to a table.
In Access on my PC (full version), everything works.
When I try to run it on a server with Access Runtime, I get an error saying something like:
this application has stopped working due to a runtime-error. The
application will now be closed
(I have the Dutch version, so I hope this comes close to the English dialog box message).
I debugged the VBA, but that doesn't seem to be the problem.
It has worked before:
Private Sub Knop62_Click()
DoCmd.OpenForm "Machines Toevoegen", , , , acFormAdd, _
acDialog, OpenArgs:=Me.Installaties_Id
End Sub
Well any un-handled error in the runtime will spit out the error message, and then as you experienced exit the application.
there are a good number of ways to approach this:
Improve error handling - make sure you don't encounter any un-handled error. I find this can be a LOT of work.
Another way? Compile your application down to a accDE. When you use a accDE, not only does the runtime ignore errors, not only does it NOT shut down?
It also means that all of your local and global variables are NEVER re-set. so global vars, and even global reocrdsets or anything else will retain their values, and do so even with errors. As a result:
Your application runs like a un-stoppable fright train.
Your local and even global variables retain their values. This allows use of application wide settings and variables that never re-set. And no re-sets ever occur even for un-handled errors. They remain intact for the given session (since the time the application was launched).
So, I would try running your application as a accDE on that server. It will not only become vastly more reliable, but it will also not shutdown on un-expected errors and even better it will retain the value of variables even when having encountered errors.
So it looks like you have some un-handed error. You can go on a treasure hunt to find this error, or just try a accDE in the meantime, and perhaps in the new years you might eventually track down the error or issue. But until then, just compile your application as a accDE.
To compile:
First, from VBA editor (just hit ctrl-g). And from the menu bar choose debug->compile. You MUST ensure that no compile errors exist before the next step.
If above compiles, then from UI (main ribbon), go file->Save and publish
From that panel, choose Make ACCDE.
Access will compile your application into a "access executable". Now try running this application with a accDE file extension on the other computer.
I randomly get an error saying HasFile is not a member of FileUpolad.
I'm using a file upload button to upload images to a server. This usually runs; however, every once in a while it errors out. Sometimes the error is caught by Visual Studio during run time, other times it will be a Server Error in Application. Compilation Error when I load the page in debug mode. I've check dependencies and everything seems to be fine. Even the IntelliSense brings up HasFile with I am writing the code.
Usually re-writing the line or restarting Visual Studio resolves the issue, but it keeps coming up randomly.
I happened to figure out what the problem was. Since it was my first time doing this I had a test class in the solution. The test class was named FileUpload. Rookie mistake. I can't believe I didn't catch that earlier!
Some background: I've been encountering this memory exception within SSMS 2012 since it was released coupled with Red Gate's SQLPrompt (this exception never happens in my SSMS 2008R2 on the same laptop).
I was originally encountering these exceptions daily (SSMS2012 and SQLPrompt) which forces me to close and reopen SSMS (along with everything I was working on). Months ago I stumbled upon a support thread that pointed possible add-on's as being the cause so I uninstalled my only add-on (SQL Prompt, but did not uninstall the rest of the developer's bundle) and went many months without a single exception much less the System.OutOfMemoryException exception.
Once SP1 was released for 2012 I applied it and reinstalled SQL Prompt again (the latest version) to see if maybe the issue had been addressed and within 7 hours of development time I was greeted again with the infamous System.OutOfMemoryException.
Through out all of this I've been opening tickets with Red Gate and submitting debug logs where they see the exception but since the memory exception doesn't explicitly list SQLPrompt they won't escalate the issue to the development team. Prior to this specific exception SQL Prompt however is throwing numerous exceptions (some listed below) within the SSMS 2012 IDE (Visual Studio 2010). I believe that the memory exception is symptomatic of an issue with how SQL Prompt manages cached data and eats up the available memory for SSMS which eventually throws an exception as a result.
I've learn how to defer this issue and how to reproduce it and it is directly related to two variables:
Connecting and working on multiple instances in SSMS (Object Explorer and Query windows). I.e. Connected to 7 instances netted the exception within 2-3 hours.
Returning result sets from multiple instances. This includes queries used by SSMS to return information to the IDE and results returned to the individual query windows.
The more instances I'm connected to the fast the exception is raised which leads me SQL Prompt's caching all of the object information per instances. Once the memory exception is raised the situation degrades until SSMS crashes completely (unless I close it first).
What I am after is how to collect more/better information to submit to Red Gate to correct this issue. This is where I need your help.
Laptop: HP Elite book 8440
RAM: 6GB
Current OS:
Win 7 Enterprise Ed Sp1
Here are some of exceptions caused by SQL Prompt:
System.ArgumentOutOfRangeException "Specified argument was out of the range of valid values."
Microsoft.VisualStudio.Text.Implementation.BinaryStringRebuilder.GetLineNumberFromPosition(N/A,N/A)
Microsoft.VisualStudio.Text.Implementation.TextSnapshot.GetLineFromPosition(Microsoft.VisualStudio.Text.Implementation.TextSnapshot,N/A)
Microsoft.VisualStudio.Editor.Implementation.VsTextBufferAdapter.GetLineIndexOfPosition(N/A,System.Int32,System.Int32&,System.Int32&)
RedGate.SQLPrompt.CommonVS.Editor.VSScriptProvider.PositionFromIndex(RedGate.SQLPrompt.CommonVS.Editor.VSScriptProvider,System.Int32)
RedGate.SqlPrompt.Metadata.Script.ScriptProviderBase.GetText(RedGate.SQLPrompt.CommonVS.Editor.VSScriptProvider,System.Int32,System.Int32)
RedGate.SqlPrompt.Engine.NewEngine.SqlPromptEngine.GetCandidates(RedGate.SqlPrompt.Engine.NewEngine.SqlPromptEngine,System.Int32)
RedGate.SqlPrompt.Engine.PromptEngineEmulator.get_GetSuggestions(RedGate.SqlPrompt.Engine.PromptEngineEmulator)
RedGate.SqlPrompt.Engine.AutoCompleter.m_FilterChanged(RedGate.SqlPrompt.Engine.AutoCompleter,RedGate.SqlPrompt.Engine.PromptEngineEmulator,System.EventArgs)
RedGate.SqlPrompt.Engine.PromptEngineEmulator.OnFilterChanged(RedGate.SqlPrompt.Engine.PromptEngineEmulator)
RedGate.SqlPrompt.Engine.PromptEngineEmulator.set_Index(RedGate.SqlPrompt.Engine.PromptEngineEmulator,System.Int32)
RedGate.SqlPrompt.Engine.PromptEngineEmulator.set_CaretPosition(RedGate.SqlPrompt.Engine.PromptEngineEmulator,N/A)
RedGate.SQLPrompt.CommonUI.Editor.EditorWindowBase.SetEngineCaretPosition(RedGate.SQLPrompt.SSMSUI.SSMSEditorWindow,N/A)
RedGate.SQLPrompt.CommonUI.Editor.EditorWindowBase.UpdateUIPrompts(RedGate.SQLPrompt.SSMSUI.SSMSEditorWindow)
RedGate.SQLPrompt.CommonVS.Editor.VSEditorWindow.OnTextViewCommandExec(RedGate.SQLPrompt.SSMSUI.SSMSEditorWindow,RedGate.SQLPrompt.CommonVS.Editor.TextViewMonitor,RedGate.SQLPrompt.CommonVS.Editor.CommandExecEventArgs)
RedGate.SQLPrompt.CommonVS.Editor.TextViewMonitor.AfterCommandExecute(RedGate.SQLPrompt.CommonVS.Editor.TextViewMonitor,RedGate.SQLPrompt.CommonVS.Editor.CommandExecEventArgs)
RedGate.SQLPrompt.CommonVS.Editor.TextViewMonitor..(RedGate.SQLPrompt.CommonVS.Editor.TextViewMonitor.)
RedGate.SQLPrompt.CommonUI.Utils.ErrorDialog.Do(System.Action)
RedGate.SQLPrompt.CommonVS.Editor.TextViewMonitor.(RedGate.SQLPrompt.CommonVS.Editor.TextViewMonitor,System.Guid&,System.Uint32,System.Uint32,System.IntPtr,System.IntPtr)
RedGate.SQLPrompt.CommonVS.Editor.TextViewMonitor..(RedGate.SQLPrompt.CommonVS.Editor.TextViewMonitor.,System.Guid&,System.Uint32,System.Uint32,System.IntPtr,System.IntPtr)
Microsoft.VisualStudio.Editor.Implementation.CommandChainNode.Exec(N/A,N/A,N/A,N/A,N/A,N/A)
System.ArgumentException 00:05:14.7510000 "The parameter is incorrect. (Exception from HRESULT: 0x80070057 (E_INVALIDARG))"
#mMc.#JQub.#OQub(#mMc.#JQub,N/A,System.Uint32,#mMc.#k3ub&)
#mMc.#JQub.#z26.#8Di(#mMc.#JQub.#z26)
RedGate.SQLSourceControl.Engine.SmartAssembly.ExceptionReporting.ErrorReporterBase.Do(RedGate.SQLSourceControl.CommonUI.Forms.ErrorDialog,System.Action,System.Predicate`1<System.Exception>,System.Boolean)
RedGate.SQLSourceControl.Engine.SmartAssembly.ExceptionReporting.ErrorReporterBase.Do(RedGate.SQLSourceControl.CommonUI.Forms.ErrorDialog,System.Action)
RedGate.SQLSourceControl.CommonUI.Forms.ErrorDialog.Do(System.Action)
And here is the Memory Exception:
System.OutOfMemoryException <null>
System.Text.StringBuilder.set_Capacity(System.Text.StringBuilder,N/A)
Microsoft.SqlServer.Management.QueryExecution.QEDiskStorageView.set_MaxNumBytesToDisplay(N/A,N/A)
Microsoft.SqlServer.Management.QueryExecution.QEDiskDataStorage.GetStorageView(N/A)
Microsoft.SqlServer.Management.QueryExecution.QEResultSet.StartRetrievingData(Microsoft.SqlServer.Management.QueryExecution.QEResultSet,System.Int32,N/A)
Microsoft.SqlServer.Management.QueryExecution.ResultSetAndGridContainer.StartRetrievingData(N/A,N/A,N/A)
Microsoft.SqlServer.Management.QueryExecution.ResultsToGridBatchConsumer.OnNewResultSet(Microsoft.SqlServer.Management.QueryExecution.ResultsToGridBatchConsumer,N/A,N/A)
Microsoft.SqlServer.Management.QueryExecution.QESQLBatch.ProcessResultSet(Microsoft.SqlServer.Management.QueryExecution.QESQLBatch,N/A)
Microsoft.SqlServer.Management.QueryExecution.QESQLBatch.DoBatchExecution(Microsoft.SqlServer.Management.QueryExecution.QESQLBatch,System.Data.SqlClient.SqlConnection,N/A)
Microsoft.SqlServer.Management.QueryExecution.QESQLBatch.Execute(N/A,N/A,N/A)
Microsoft.SqlServer.Management.QueryExecution.QEOLESQLExec.DoBatchExecution(Microsoft.SqlServer.Management.QueryExecution.QEOLESQLExec,Microsoft.SqlServer.Management.QueryExecution.QESQLBatch)
Microsoft.SqlServer.Management.QueryExecution.QESQLExec.ExecuteBatchCommon(Microsoft.SqlServer.Management.QueryExecution.QEOLESQLExec,N/A,N/A,System.Boolean&)
Microsoft.SqlServer.Management.QueryExecution.QEOLESQLExec.ExecuteBatchHelper(N/A,N/A,N/A,N/A)
Microsoft.SqlServer.Management.QueryExecution.QEOLESQLExec.ProcessBatch(N/A,N/A,N/A)
.BatchParser.ThunkCommandExecuter.ProcessBatch(N/A,N/A,N/A)
Again, to be clear, I don't know if the other exceptions are related or not but the memory exception only happens with SQL Prompt installed.
Thanks for your assistance!
At this point RedGate has finally admitted the issue is that the SQL Prompt plug-in is working in-process with the 32-bit SSMS client and eventually chokes the memory resulting in the out-of-memory exception.
Their response to a fix for this would be "maybe" in a year or so which, when you are paying for annual support, is a slap in the face. I've since refused to pay for further support for 2 existing Tool-belt licenses over this issue, an issue that I have fought with since 2012, until they correct this. If this is affecting you then, and if you can, do the same and vote with your wallet to motivate them to make this fix a higher priority.
If and when that day comes I will update this answer post with the version information of the corrected build of SQL Prompt that no longer operates within the 32-bit memory space of SSMS.exe.
What works for me is Disabling Code suggestions in SQL prompt, then I can run the same query and then get the results.
I can then Enable Code suggestions in SQL prompt and the error stays away for a while.
Can you try limiting the number of columns as described in this post and see if it helps?
http://redgate.uservoice.com/forums/94413-sql-prompt-feature-suggestions/suggestions/1364757-disable-sql-prompt-on-certain-databases
I developed a small application which accesses a MS access database on my computer using VB.net. I developed the program on windows xp 32 bit. At the moment I am using windows 7 64 bit and the program simply will not run. I get a null reference exception when I try to do anything to the database. I have narrowed this down i THINK to the db provider. I was using Provider=Microsoft.Jet.OLEDB.4.0; and tried using Provider=Microsoft.ACE.OLEDB.12.0;. Neither seems to work. The path to my database is 100% correct. This is the error I am getting:
Null reference exception was unhandled.
Object reference not set to an instance of an object.
Like I say the program runs fine on the windows xp machine. If it helps the access database file extension is mdb.
No DLL exist for 64 bit access to Access database files so you must go to the project properties and on the "Compile" tab go to "Advanced Compile Options" and set "Target CPU" to "x86" I hope this helps.
I was having the exact same problem, except writing to a SQL 2008 DB. VS2008, VB.net code with framework 3.5, Windows 7 64-bit. Code runs fine on XP.
John R's answer provided the right solution: changing the project's advanced compile options to set "Target CPU" to "x86".
This problem can have more symptoms than originally described. I'll generalize them:
Accessing ACCESS isn't the only problem; it happens with SQL (at least MS SQL 2008) too.
Some of the DB calls can and do work. It's as if the calls set you up for failure, but the point of failure happens later, at a random point in your program.
The point of failure I saw was during a subroutine call. (just a normal call to a subroutine I created in VB.) Putting a try-catch block around the call wouldn't catch the error though.
Here's the strangest part: Previous to the errant subroutine call, the code had a HANDLED exception. Ironically, the exception was EXACTLY what was being thrown at the errant call. When I "tweaked" the code to avoid the prior exception, NO exception was thrown at the errant call; the VB program JUST QUIT WITH NO ERROR! It appears that whatever code is having the problem, it is reusing the last handled exception. This would mean that if your code previously had an "index out of bounds" or "divide by 0" error, this is what you'd (probably) see when the code barfs (because of no 64-bit dll.) So this problem can masquerade as a whole bunch of errors!
Doesn't sound like a Provider error because the Jet part is fine. Make sure your Data Source path is correct. If you have it in your Projects folder on VS and are using a full path it may need to change because of how the file system is set up with Users vs Documents and Settings.