My C++ app needs to deal with SSCE database files belonging to different versions. Right now, I have no way of knowing the version of the database.
The problem is that if the version of the OLEDB SSCE provider mismatches the version of the database file, IDBInitialize::Initialize() fails with E_FAIL. One has to obtain the respesctive IErrorInfo object to get a meaningful error message.
The point is that the error code of E_FAIL does not tell me whether the failure is because of the version mismatch or for some other reason. In the first case, I should retry with another SSCE provider, while in the second the application should terminate.
How can I implement this logic? Is there some API that I can invoke before calling IDBInitialize::Initialize() to check the version compatibility? Is there a way to get the real error code instead of the opaque E_FAIL?
Thanks.
You can look at the first bytes of the file - see this sample in C# - http://erikej.blogspot.com/2010/08/how-to-upgrade-version-3x-database-file.html
Related
I'm working on a custom Linux BACNet compatible device. I've stopped my search on BACNet Stack.
I've been able to build from the latest version on github, also been able to test both readprop and writeprop with server from the build directory (examples provided). I had to edit the writeprop to make it properly work, but this is not the point here.
Now, I'm wondering what is the good way to implement a device that will answer to read-property requests. In the server example, there is one handler that could be the way :
apdu_set_confirmed_handler(
SERVICE_CONFIRMED_READ_PROPERTY, handler_read_property);
but I'm confused when I go into source of h_rp.c I see the function Device_Read_Property is called, which make more sense to overload? This function seems to belong to device.h.
So, should I overload Device_Read_Property ? Seems like the library is missing a device implementation comprehensive example.
I have a C# app targeting Windows-10 desktop platform.The C# app calls into native component written in C++. My native C++ code has Visual C++ component extensions(C++/CX).
I am trying to run WACK test for my app & I am seeing this error:
Error Found: The general metadata correctness test detected the following errors: The overloaded method XXX in yyy.winmd have the same number of in parameters without one that has DefaultOverloadAttribute. Exactly one method overload must have DefaultOverloadAttribute
Impact if not fixed: Windows store doesnt allow apps that don't pass Windows Runtime Metadata Validation.
How to fix: Please ensure that the compiler you are using to generate your Windows Runtime types is up to date with the Windows Runtime specifications
This used to work fine with VS-2015 Update 2. I installed VS-2015 Update-3 today & from then I am seeing this failure.
The strange thing is that the overloaded method mentioned in the Error Report is not overloaded at all.
I have checked this MSDN page but couldnt find any solution.
My VS details are as follows:
MS VS Professional 2015
Version 14.0.25425.01 Update 3
MS .NET Framework
Version 4.6.01038
I couldnt find any Windows Runtime Specifications anywhere. Do I need to anything additional after installing VS Update-3 ?
This seems to be a VS compiler issue. Basically WACK tool is complaining about any user defined method name "Close"
The compiler adds an IClosable implementation whenever user defined ref class has an explicit destructor. It then maps the destructor to "IClosable::Close" method. But the compiler is not complaining about user defined method named "Close".
On further digging, I found that SQLite also seem to have similar issues. This is exactly the issue which I am hitting as well.
This is the solution employed by SQLite.
After looking at the SQLite solution, I then modified my method name from "Close" to "Closedb" and now my WACK tests pass.
As of this posting the only resolution for this issue seems like not to have a method named "Close" in your code.
It's a very strange thing... We have a common cross platform base which contains a web service client (SOAP). On all platforms it's working very well but on WinRT we get the following:
IOException: The specified registry key does not exist.
After checking the queries on the registry I've found out, the program tries to access a Clsid which does really not exist (with procmon).
There is no StackTrace and HResult is 2.
I really don't know what I could do to find out more about this error.
Someone else encountered problems like this?
In a program I'm developing I need to gather information about runtime errors. Currently, I am able to gather all the information I need, including the message via FormatMessage, but the identifier of the error (for example, ERROR_SUCCESS). I know that when the application is compiled these identifiers are not actually present in the binaries.
Is there a function in the Windows API which can retrieve these identifiers or do I need to store them with my application?
ERROR_SUCCESS itself is just a constant. I haven't found a way to go from number -> constant identifier.
You could scan WinError.h with Clang and create some kind of table for your application.
Here is a nice example of how you can get the ErrorCode and how to translate it to a more readable message on MSDN.
No need to copy that over, its quite plain:
Retrieving the last error code and message
I have a Delphi web server providing some web services*. One of them is supposed to generate and return a PDF report.
The PDF creation is done with a QReport that is then exported into a PDF file with the ExportToFilter procedure.
The routine works fine when called from within an application, but when called behind a TIdTCPServer, it hangs and never finishes. Debugging it, I got tho the hanging point:
(note: I'm home right now and I don't have the source code. I'll try to reproduce quickrpt.pas' source as accurrate as I can remember).
procedure TCustomReport.ExportToFilter(TQRDocumentFilter filter);
...
AProgress := TQRFormProgress.Create(Application); // Hangs on this line
AProgress.Owner := QReport;
if ShowProgress then AProgress.Show;
QReport.Client := AProgress;
...
Searching the web, I found in this page (1) the suggestion to set ShowProgress to False, and edit the code so that it does not create the progress form when ShowProgress is set to false (apparently, this is due to QReport not being threadsafe).
So, I edited the code, and now I have this:
procedure TCustomReport.ExportToFilter(TQRDocumentFilter filter);
...
if ShowProgress then
begin
AProgress := TQRFormProgress.Create(Application);
AProgress.Owner := QReport;
AProgress.Show;
QReport.Client := AProgress
end;
...
Now, the report comes out. But then the service gets to an Invalid Pointer Exception (which I can't trace). Following calls to the service complete successfully, but when I shut down the service** it starts whining again with Invalid Pointer Exceptions, then the "MyServer has commited an invalid action and must be closed" windows message, then again a couple of times more, then just the pointer exception, then comes to error 216 (which as far as I could find out, is related to Windows access permissions).
Thanks!
Update (jan 5): Thanks Scott W. for your answer. Indeed, after some research, I found another suggestion that only the main thread can access some components. So I set the QR code back to normal and called the main method from a Synchronize call inside a TThread (so that way the main thread would handle it). But I still get the same error.
You mention you were able to generate PDF as a service with QR 4. Maybe that's why it's not working for me, since I'm using QR 3. On the other hand, you don't mention if you're doing that behind a TIdTCPServer (which is my case, providing web services) or if you run it by itself (for instance, during a batch process).
Anybody knows whether my QR version might be the problem? Thanks!
* Running Delphi 7 and QuickReport 3 on a Windows XP SP2. The server is based on Indy.
** I have two versions of the server: a Windows application and a Windows Service. Both call the same inner logic, and the problem occurs with both versions.
Update (mar 8): After all, my problem was that my printing routine was in another dll, and the default memory management module is somewhat crappy. Setting the first uses of my .dpr to be ShareMem overrides the memory management module with Borland's implementation, and solved my problem.
uses
ShareMem, ...
(1): http://coding.derkeiler.com/Archive/Delphi/borland.public.delphi.thirdpartytools.general/2006-09/msg00013.html
I'm guessing that QReport.Client is used somewhere later in the code, and with your modified code no longer assigning it to AProgress, you end up with an error.
Are you sure that you have to modify the QuickReport source? I have used QuickReport in a Windows Service to generate a PDF file and then attach to email message and all worked fine without having to modify the QR source. I don't recall exactly which settings had to be made, but it was done with Delphi 6 and QR 4.06.