My problem is about report viewer, I didn't know what is the cause of this problem. And it is only occurring occasionally. The problem says something like
Local Report Processing
-----------------------------------
...The process access the file path path\expresion_host_5bc339f79dc24f2fb4b34667e9fadb13.dll
because it is being used by another process
(sorry for not providing complete details, or image, they just chat me this)
but it didn't run, after close the form, i dispose the reportviewer and form, and if re-open it and do it many times, this error will show. And i'm freaking here to solve this, i tried to google it first but none of them help me with this.
by the way, in my workspace, this error is not showing.
but in my boss, this error is showing, maybe because he is using Windows 8.
1.) Application Run As Administrator
2.) When you Close Application at that time use Application.exit at end of code
When a report ( printing ) function is run, a dll ( it is a working temp file generated by application to set a parameter etc.. ) is created in a temp folder for a millisecond and deleted.
At that time if the new antivirus program is catch the file, it also checks and release. and it is locked while it is being checked and your application dump ( the error message ) at that time.
So remove your anti virus you will see problem will be solved. Stopping anti virus may not enough. AV services continue to check every file and blockes.
Related
Im developing a system using vb2022 its almost done but today the changes I made doesn't reflect on run time.
For example I added a button but when I run the program the button will not show.
Same as the code, i can write code but it doesnt reflect on run time
Plus im trying to change the startup form into form 2 (initial is form 1) but it doesn't reflect.
What should I do? I didn't change anything I just opened the file and write code. But suddenly this happened.
Most likely your build is failing and VS is automatically running the old output. When that happens, VS will prompt you whether to run the old output or not by default, but many people tell VS not to prompt them again without actually reading the dialogue. Use the Build menu to build your project/solution and pay attention to the Output and Error List windows to see whether it failed or not.
It may be that the compilation is succeeding but VS simply can't overwrite the output files because they are locked, which does happen sometimes. In that case, just delete the entire obj and bin folders from your project folder. You may need to close VS to do so. The next time you build, new output will be created and run.
If this happens regularly then you should probably repair VS and, if it continues after that, reinstall.
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 have an MS Access (2013) application with a split database. Everything seems to run smoothly except for occasionally I will get Error 3048: Cannot open any more databases.
The error occurs when the front end tries to run vba code which involves pulling data from the back end and will stall on any line with: Set DB = OpenDatabase() or DoCmd.RunSQL() commands.
The strange thing is that this error seems to be time based. I can access the back end hundreds of times without error if I do it quickly enough but after some time has passed (~1 hr) the error shows up. In fact, I can open the application and leave it running in the background (with no code running) then go back into it after an hour and I will get the error the first time the code tries to open the back end.
I've searched the length and breath of this site and google for solutions so I know this error has been addressed before. To save people reiterating the usual fixes I will list what I've tested for so far with no success:
Recordset limit: I'm not leaving any recordsets open, every time I open one I make sure to close it. The same for the databases. All my requests
to the back end are done via 3 or 4 vba functions and each of these has
a Rec.Close or DB.Close corresponding to every OpenRecordset()
and OpenDatabase() and I never have more than 2 recordsets open at
a time.
Control limit: I have 151 controls on the biggest form in the application so I should be below the limit (I believe this is 245 for a single form?)
Corrupt database: I've copied all my forms and code to a new Access database and run a Compact and Repair.
Machine Issue: I've tested the application on several machines and reproduced the same error.
Anyway with most of the above situations I would expect the application not to run at all, instead of running fine for a set amount of time and then crashing.
Some other points of note:
Citrix Users: The users are split between normal windows machines users who are experiencing this error and others who are using the application through a virtual desktop software (Citrix) who are having no issues. Unfortunately I don't know enough about this virtual desktop to really work out what that implies.
Background vs Foreground: Some users have claimed that the application only crashes if it has been running for a long time AND they switch over to another program and switch back. I've confirmed that simply switching between the application and other programs doesn't cause it to crash but haven't yet been able to leave it running in the foreground long enough to confirm if it crashes without switching between programs.
I've been struggling with this for days, anyone able to help me out?
Anybody know why the below error exist?
CrystalDecisions.CrystalReports.Engine.LoadSaveReportException: Load report failed
From your comments about windows\Temp, that is caused by the application pool's identity not having access to c:\windows\Temp (and possibly to the reports folder).
You can solve this problem by giving the application pool credentials that do have the necessary permissions, or giving read write permissions to "Network User" to the c:\windows\temp folder (and again, possibly to the reports folder).
The reason why this folder is required is that the crystal runtime creates a dynamic copy of the report at runtime and places it in the %temp% folder. It is the temp folder copy (with a GUID appended to the original file name) that is shown in the web browser. This is by design and is a useful feature to ensure the live report is safe.
Following from this, you will have to do a proper cleanup after loading every report because they just stay there and fill up the temp folder!
Something like:
CrystalReportViewer1.Dispose(); // if using the viewer
CrystalReportViewer1 = null;
report.Close(); // I can't remember if this is part of the reportDocument class
report.Dispose();
report = null;
GC.Collect(); // crazy but true. Monitor the temp folder to see the effect
Reckface's answer was clear enough, but to add something up.
I managed to get it working using this:
protected void Page_Unload(object sender, EventArgs e)
{
if (reportDocument != null)
{
reportDocument.Close();
reportDocument.Dispose();
crystalReportViewer1.Dispose();
}
}
Doing so may cause issues with the buttons on the toolbar, they can't find the document path anymore because the document is disposed. In that case the document needs to load the path again during postbacks: source
This is a very old question, but I want to add that I got this error because the report was not embedded into the class library.
Solution: I removed the report from the project. I restarted Visual Studio 2022 and than added the crystal report again. This time it was added as an embedded resource.
Did you even bother to Google it? This is a common exception; there are hundreds of posts about it scattered around the intertubes.
The Crystal .NET runtime has famously cryptic error messages. This one just means that the .rpt file (or embedded report) could not be loaded. There are several possible root causes: wrong filename or path, security violation, you are not disposing of old reports properly and windows/temp is getting hogged up, etc.
Do some research. If you're still stuck, come back and elaborate on the problem (do any of your reports work, is this a web app?, what code are you using, etc.)
I have a Window Forms application (using clickonce installation, running on a terminal server) that occasionaly ends up with a thread that appears to be running in a tight loop. The user doesn't know this happens as the app continues to run as expected. Also I have determined that I can kill the problem thread without any apparent affect on the app.
I can use Process Explorer to find the instance of an app with the problem and can isolate the thread with the problem but haven't found any way to look into the thread to find anything that would help me determine what is causing the problem. Does anyone know of a way to some additional information about a thread, like maybe strings, that would help me zero in on the issue?
Thanks,
Dave
Haven't tried this myself but "Process Monitor" claims it "shows real-time file system, Registry and process/thread activity"
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Hope this helps.
You should be able to attach Visual Studio to the running process to get more information. Provided the .pdb files are included with the application and you have source code for the avialable version you should be able to use the Threads window combined with pausing / stepping through to see just what the code is doing.