I am creating a project windows runtime component(with c#), and I want to use embedded DB so I added Firebird-2.5.2.26540-0_x64_embed and .net component NETProvider-2.5.2-CF. Every time when I am performing any action on FBcommand and FBConnection i am getting error "An unhandled exception of type 'System.NotSupportedException' occurred in FirebirdSql.Data.FirebirdClient.dll"
I can't use terget framework because its WinRT(c#) project...
Note this answer is actually by #cincura.net on the Firebird .NET mailinglist. I am just posting it here for completeness:
The ADO.NET stack is not available in WinRT, hence you cannot use any
database access. The CF version didn't helped either.
See How should a Windows 8 Metro Application connect to a central database? and How might a Windows 8 Metro app handle back end database access? for potential solutions.
Related
I'm building an application using delphi 7 with ms access 2007 as the database for a client. it runs normally on my laptop (asus) but after I copy the whole project folder and run the Project.exe, it gives me an error "Disk write error".
I've tried googling about "disk write error delphi application" but only found about I/O errors. my application only opens a file after a button click in a form that is called when I click on a submenu, so I'm guessing it's not about I/O..
what is the solution?
thanks in advance
P.S.:
in the project options, the checkbox for building application using runtime packages is already unchecked.
my PC and my client's PC are both using windows 7 32bit (I haven't actually confirmed this with him but I'm guessing he's also using 32bit version because he's not a techy guy)
his PC doesn't have delphi installed
UPDATE :
I forgot that the exact error message was "Disk or network error" instead of "Disk write error".
after googling for the correct error message, I've found out that the problem is that I use a full path for the DataSource in the ADOs' connection string. after I change connection string into "DataSource=.\db\my_db.mdb", the application works perfectly.
even though this question has a negative mark, I'll just leave this solution here in case someone needs it in the future...
Here are some different questions.
The "Disk write error" probably is that you need permissions to write in the folder. A simple test is that you execute your application with "admin permissions" to test this.
Different question is the "using runtime packages" check in project options.
If you compile your application with this check, you need to copy the BPL's needed for your application with the executable.
If you compile with this option unchecked, your exe file include all the libraries for execute (not included DLL's or external dependencies).
I'm using Embarcadero Delphi XE3 on Windows 8 and I'm trying to connect with SQL Server 2000.
My program used to work correctly when I was using Delphi 2007 on Windows 7,
but now whenever I do transaction (Update, Insert, Delete) it gives me an error message saying "Cursor Operation Conflict" and continue working (commit the transaction).
I'm using TADOConnection to connect with the server
and I use TADODataSet to do transactions. I use TADODataSet.Insert/ TADODataSet.Edit/ TADODataSet.Post/ TADODataSet.Delete to do the transactions.
I couldn't post any piece from the code because it is general problem.
I would like to know what may cause this error to be able to debug my code and make sure that I'm not doing any wrong....
The error only appears when I use clUseServer in TADODataSet.CursorLocation property.
i had the same error with some VB6 code, it even happened when i used a disconnected adodb.recordset
my solution was to create an entirely separate connection (to the same server) for my record set which seemed to resolve my issue
i don't know much about delphi but i thought it could possibly help
I've a problem using ADO and indy in Delphi 2009.
My project always crashes on exit when running in delphi 2009.
This can be reproduced by doing the following in delphi 2009:
Create a new project
Add TAdoConnection component to the form. Create a connection to a sql server database and set the connected property to true.
Add IdHttp to the uses clause of the form.
Run, on closing the application the error occurs every time.
This is the error details
Problem Event Name: APPCRASH
Application Name: Project1.exe
Application Version: 0.0.0.0
Application Timestamp: 4e787e97
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7601.17514
Fault Module Timestamp: 4ce7ba58
Exception Code: 4000001f
Exception Offset: 000a2562
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 2057
Additional Information 1: d1ab
Additional Information 2: d1ab624ec7d094c26a73530c245a3468
Additional Information 3: d1ab
Additional Information 4: d1ab624ec7d094c26a73530c245a3468
As soon as I remove IdHttp from the uses clause, no error occurs.
Anyone got any ideas as to what i can do to sort this out, or suggest a different component suite to Indy I can use for http.
Indy is completely separate from ADO. There is no way the mere presence of the IdHTTP unit in the uses clause (especially if you are not actually using the TIdHTTP component) can cause such a crash. Something else has to be happening, and removing the IdHTTP unit is just a coincidence. You are going to have to step through the app's shutdown code to see what is really happening.
This is probably old news now but I had exactly the same issue but had neglected to install Update Pack 4 after a reinstallation. Do so cured the problem.
I am creating a runtime package which contains classes that my main application can use, but I'm having problems with the data access.
My main app contains a TDatabase which points to a BDE alias. At runtime my package is dynamically loaded, and a method invoked in the package which creates a TQuery and opens it, populates an object with the returned data and then returns the object to the main app. The TQuery uses the TDatabase in the main app to connect to the database.
All this works fine, but when I close the app I get an access violation: "Project C:...GUI.exe faulted with message 'access violation at 0x7c9102db: write of address 0x00040ffc'. Process Stopped. Use Step or Run to continue".
If my method creates the TQuery but doesn't open it then this error does not occur. I have no idea why this happens! When I close th app my TQuery is closed and freed ok, my package is unloaded ok, but after the form is destroyed the error occurs.
I'm using Delphi 5 BTW, I've tried to be brief so if I have missed out any helpful info let me know, any help gratefully received.
Thanks
p.s. I know that using Delphi 5 and BDE is archaic but I'm stuck with it for now!
What if you don't free your TQuery? I mean, try not to free your TQuery object when application terminates.
This happened with me using dbExpress, the finalization section would fire before a datamodule destructor, when application was Abort()ed and that caused a lot of head ache.
So, my guess would be that
BDE's connection driver (or some other resource) is finalizing before the destruction of something that uses it, therefore attempting to finalize the connection twice.
I say driver because those are usually only loaded/initialized on demand, thus it wouldn't fault if it wasn't used. So, maybe when your package is unloaded it finalizes the drivers.
Try this:
load your package,
use the TQuery contained in the package,
unload your package,
use another TQuery created in the main application,
and see if this works without raising exceptions. If it doesn't work then I guess I could be right, and we'll try to figure out how to make this work.
God bless!
Sounds like a unit initialization/finalization order issue. Usually that is determined by the order of units in the uses lists, and what packages your package requires.
Best way to try to solve it is to debug Delphi with Delphi, or your package with a .EXE.
The last one is important, because older Delphi versions won't always find the symbols for your package if you start debugging with your EXE.
Steps
Start a Delphi that does not contain your package
Load your package in Delphi
Set the host of your package to be Delphi
Compile your package with full debug information, and enable the option 'debug DCU's'
Run your package (it should now load Delphi, then your package)
Terminate Delphi
Watch the call stack when the AV occurrs
You might want to set breakpoints to watch your initialization/finalization order (see this post, the references and the comments for a discussion on that).
Then fiddle with your uses lists and package requirements sections.
--jeroen
When an application is run from within the IDE and the debugger is attached the exception 'External exception C0000008' is raised when it tries to connect to an imported ActiveX control.
If the application is ran standalone or the Rad Studio options/ Debugger Options/ Integrated debugging is unchecked, the program works as expected, no exception and the ActiveX control returns the expected result.
There are other ActiveX controls in the project, all of which work fine.
I have tried:
- Reinstalling the ActiveX control
- Re-Importing the ActiveX control
- Removing any software that may be causing conflicts (experts/ plug-ins etc)
- Turning off most running applications and services etc in case they are causing a conflict
Searching Google, It looks like others have been experiencing the same problem, but there is no fix to be found (other than turn off Integrated debugging, but obviously that is not a valid option.
Does any one have any ideas were to look to fix this problem?
I am using Delphi 2007
C0000008 is the status returned for an invalid handle. Make sure that your wrapper when it goes to create the object gives it a proper handle and not nil (assuming it is crashing because of a windows handle).
Since the application runs fine when not attached to the debugger, I'm assuming that the wrapper is handling this condition gracefully so the error is most likely occurring inside a try/except block.
It's a combination of non-obvious function behavior and IDE options.
MSDN CloseHandle
If the application is running under a debugger, the function will throw an exception if it receives either a handle value that is not valid or a pseudo-handle value. This can happen if you close a handle twice, or if you call CloseHandle on a handle returned by the FindFirstFile function instead of calling the FindClose function.
So there's two options - either check the code for a place where some invalid handle is being closed or turn off IDE's notification of this exception. Go to Tools > Options > Debugger options > Emb debuggers > Native OS exceptions, find Invalid Handle item and change On resume option to Run handled. This worked for me.
Credits for this solution go to _Vasilisk_ from sql.ru forum.