I do not have the VB6 dll source from my provider, so I have no way of getting the error.
I am attaching images of errors captured by SQL Profiler, but I don't think they can help.
The 1.png, 2.png and 3.png files are screenshots of the SQL profiler traces captured at Runtime, while the 1_Debug.png, 2_Debug.png and 3_Debug.png files are screenshots of the SQL profiler traces captured in Debug (so working).
Since the errors do not occur by calling the VB6 dll from VB6 or VB.NET applications, or by debugging my VB6 project which instantiates the external dll, I thought the problem lies in the process that hosts it.
All the messages seem to be complaining about the syntax of the SELECT clauses (assuming my innterpretation of the Italian is coorect), and suggesting that it has something to do with the Date values. I think the only way to resolve this is to talk to the owners of the DLL.
What Dave said might be correct too, since Service is to transport the Data it must be Serializable or Distributed that would be a problem but to know the real problem - try to replicate the issue on Stored Proc by passing different Date formats as I can guess you have only one source code that's exposed to you all other are either dlls or exes, which you can't reverse them into VB6 code back. So focus on one Source Code you may probably have or know that's SP and try to replicate the problem.
Checking the VB6 code with the developer, we have identified the point where the error occurs: it cannot return a path of the configuration file (from which it reads the formatting of the dates), and uses the Windows API "GetEnvironmentVariable" .
I'm trying to figure out if there is any incompatibility between WCF and the VB6 API calls.
If you're hosting the WCF service in IIS or a Windows Service, it will be running under a different profile. Unless the environment variable is set as a system variable, it will be specific to your user profile, and will not be available to the WCF code.
in my application taht runs in Windows Embedded Compact 7 OS (with Compact Framework 3.5) I have a problem reading a xml file with DataSet.ReadXml.
I have made a little test to reproduce the problem:
PrivateSub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim dati As DataSet = New DataSet("Programmazione")
Dim fname AsStringDim j AsInt32Try
fname = "\Program Files\SmartDeviceProject1\default_19.prg"'this works'fname = "\Program Files\SmartDeviceProject1\default_20.prg" 'this doesn't workDim fs AsNew FileStream(fname, FileMode.Open, FileAccess.Read)
Dim xr As XmlReader = System.Xml.XmlReader.Create(fs)
j = dati.ReadXml(xr) 'j = 3 = XmlReadMode.InferSchema
Catch ex As Exception
I have two test file: default_19.prg and default_20.prg.
The first is a little shorter than the second and it is read without problem, the second fails without raising an exception (at least an exception that I can catch).
I don't know if it is a file dimension problem or something else.
The two files are quite long and I apologize for this but I post them here otherwise who could help me?
surely a StackOverflowException means something bad, for this reason I tried to reproduce the problem with few clean lines of code.
I managed to replicate the problem just with a Form, a Button and the code I posted.
This does not mean that the complete application would not benefit from a reworking (...) but it seems to me that in this situation the problem is in a single line of code.
Probably, as Eddy suggests, I should use another way to store and read the application settings.
surely a StackOverflowException means something bad
Yes, as I already explained it means you have used up all your local memory (stack space). If that is because you are reading huge amounts of data then that is the area that needs investigation. If that is not the reason (which is also possible) then more debugging may be required. In either case the only way to be sure is to use the debugger to see what is happening inside the application under real load.
These files are created by the application and contain user programming.
They can be larger or smaller depending on what the user does.
When the user changes something, the file is updated.
While the application is running, there is no problem.
When the application is closed and restarted, settings are loaded from the file and here is the crash.
I load the XML file in a DataSet because I can read all with a line of code with ReadXml and then I copy the DataSet content in the different internal variables and structures; I don't use a real database.
To limit the file size and use more than one if one file is not enough could be a solution.
If ReadXml works fine in a desktop environment with full .NET, perhaps there is a bug in the .NET Compact Framework version of this function?
Last Visit: 2-Dec-20 6:21 Last Update: 2-Dec-20 6:21