Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 7 of 7 total |
Client-Server access locking via DLL revisited |
Tue, Nov 11 2008 6:20 AM | Permanent Link |
"Al Vas" | Hi,
We spoke about an issue with client-server and calling from dlls which we managed with Tim's help to solve using Delphi. However our business partner is making calls to the DLL and when the application exits it remains in memory and takes up 50% CPU usage time as it appears to not be able to release the connection to the database engine. This is only an issue with client-server mode and the dll works fine in non client-server mode. They are using Visual Studio 2005 VB.NET. They say they are using a dynamic call rather than static but being unfamiliar with VB.NET I dont know myself. Was wondering if anyone has any ideas at all. Anyone with VB experience that might know about dll calls? I have included the code they use below, in particular the favourHROHS.dll code: Thanks for any help anyone can provide. Regards Alex <DllImport("kernel32.dll", EntryPoint:="LoadLibraryA", SetLastError:=True, _ CharSet:=CharSet.Unicode, ExactSpelling:=True, _ CallingConvention:=CallingConvention.StdCall)> _ Public Shared Function LoadFunctionPath(ByVal Path As IntPtr) As Integer ' Leave the body of the function empty. End Function <DllImport("kernel32.dll", EntryPoint:="FreeLibrary", SetLastError:=True, _ CharSet:=CharSet.Unicode, ExactSpelling:=True, _ CallingConvention:=CallingConvention.StdCall)> _ Public Shared Function FreeLibrary(ByVal hModule As Integer) As Integer ' Leave the body of the function empty. End Function <DllImport("kernel32.dll", EntryPoint:="GetProcAddress", SetLastError:=True, _ CharSet:=CharSet.Unicode, ExactSpelling:=True, _ CallingConvention:=CallingConvention.StdCall)> _ Public Shared Function GetProcAddress(ByVal hModule As IntPtr, ByVal hModuleName As IntPtr) As IntPtr ' Leave the body of the function empty. End Function <DllImport("favourHROHS.dll", EntryPoint:="EmployeeNew", SetLastError:=True, _ CharSet:=CharSet.Unicode, ExactSpelling:=True, _ CallingConvention:=CallingConvention.StdCall)> _ Public Shared Function EmployeeNew(ByVal src As IntPtr) As IntPtr ' Leave the body of the function empty. End Function <DllImport("favourHROHS.dll", EntryPoint:="EmployeeGetData", SetLastError:=True, _ CharSet:=CharSet.Unicode, ExactSpelling:=True, _ CallingConvention:=CallingConvention.StdCall)> _ Public Shared Function EmployeeData(ByVal src As IntPtr) As IntPtr ' Leave the body of the function empty. End Function <DllImport("favourHROHS.dll", EntryPoint:="EmployeeUpdate", SetLastError:=True, _ CharSet:=CharSet.Unicode, ExactSpelling:=True, _ CallingConvention:=CallingConvention.StdCall)> _ Public Shared Function EmployeeUpdate(ByVal src As IntPtr) As IntPtr ' Leave the body of the function empty. End Function |
Tue, Nov 11 2008 2:18 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alex,
<< They are using Visual Studio 2005 VB.NET. They say they are using a dynamic call rather than static but being unfamiliar with VB.NET I dont know myself. Was wondering if anyone has any ideas at all. Anyone with VB experience that might know about dll calls? I have included the code they use below, in particular the favourHROHS.dll code: >> The call declarations are fine. The issue is whether they are calling FreeLibrary or not in their actual code, since that is what will unload the DLL. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Nov 11 2008 7:00 PM | Permanent Link |
"Al Vas" | Hi Tim
Here is the code making the calls. Any ideas greatly appreciated. Alex Declarations ModuleHandle As Integer, MethodPointer As Integer = 0 Loading the Library Path = Path & "\\favourHROHS.dll" InputPTR = Marshal.StringToHGlobalAnsi(Path) Outputintprt = LoadFunctionPath(InputPTR) 'ModuleHandle = Marshal.PtrToStringAnsi(Outputintprt) ModuleHandle = Outputintprt FreeLibrary If ModuleHandle <> Nothing Then 'InputPTR = Marshal.StringToHGlobalAnsi(ModuleHandle) OutputPTR = FreeLibrary(ModuleHandle) 'OutputPTR = FreeLibrary(InputPTR) 'Output = Marshal.PtrToStringAnsi(OutputPTR) If OutputPTR > 0 Then Result = True ModuleHandle = IntPtr.Zero End If End If EmployeeNew InputPTR = Marshal.StringToHGlobalAnsi(Input) Outputintprt = EmployeeNew(InputPTR) Result = Marshal.PtrToStringAnsi(Outputintprt) EmployeeUpdate InputPTR = Marshal.StringToHGlobalAnsi(Input) Outputintprt = EmployeeUpdate(InputPTR) Result = Marshal.PtrToStringAnsi(Outputintprt) EmployeeData InputPTR = Marshal.StringToHGlobalAnsi(Input) Outputintprt = EmployeeData(InputPTR) Result = Marshal.PtrToStringAnsi(Outputintprt) > The call declarations are fine. The issue is whether they are calling > FreeLibrary or not in their actual code, since that is what will unload > the DLL. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > |
Wed, Nov 12 2008 1:12 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alex,
<< Here is the code making the calls. Any ideas greatly appreciated. >> It looks okay. Did you run something like Process Explorer: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx and step through the code to make sure that the DLL is actually unloaded when FreeLibrary is called ? You need to verify that the library is a) being loaded when LoadLibrary is called and b) unloaded when FreeLibrary is called. If the DLL is being loaded at application startup, then there's still a static, compile-time reference to the DLL in the host application. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Nov 12 2008 4:43 PM | Permanent Link |
"Al Vas" | Hi Tim,
Thanks I'll pass the message on. Just quickly (if there is such a thing) what does your statement below mean about there still being a static, compile time reference? I presume starting the DLL at application startup is the only way to do it. Alex "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:0ADCE8A9-E6BE-478E-8C8A-CA30C97EF72E@news.elevatesoft.com... > > and b) unloaded when FreeLibrary is called. If the DLL is being loaded > at application startup, then there's still a static, compile-time > reference to the DLL in the host application. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > |
Thu, Nov 13 2008 3:25 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alex,
<< Thanks I'll pass the message on. Just quickly (if there is such a thing) what does your statement below mean about there still being a static, compile time reference? I presume starting the DLL at application startup is the only way to do it. >> You can load a DLL in two ways, one is via a static reference in the actual code that causes the DLL to be loaded automatically by the application at runtime, and via a dynamic load using the LoadLibrary/FreeLibrary calls. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Nov 14 2008 9:04 PM | Permanent Link |
"Al Vas" | Thanks for all your help Tim, it ends up the dll was being loaded twice but
only being freed once. All great now. Alex "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:277A0FA2-1907-454F-830D-A39FBD4E6DF7@news.elevatesoft.com... > Alex, > > << Thanks I'll pass the message on. Just quickly (if there is such a > thing) what does your statement below mean about there still being a > static, compile time reference? I presume starting the DLL at application > startup is the only way to do it. >> > > You can load a DLL in two ways, one is via a static reference in the > actual code that causes the DLL to be loaded automatically by the > application at runtime, and via a dynamic load using the > LoadLibrary/FreeLibrary calls. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > |
This web page was last updated on Friday, March 29, 2024 at 03:30 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |