I'm trying to get a web application working with a reference to Sap.Data.SQLAnywhere.v4.5 and having an issue running is locally. It works fine if deployed on the same server that 17 is installed (although it's returning data from a version 11 server as well).
I suspect the issue is it requires some more resource files (it kicked off wanting dblgen17.dll so I dropped a copy of that in resources and that error dropped) - now it's having a connection issue (0x80004005)..
Found this for an earlier edition
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sqlanywhere.12.0.1/dbprogramming/adaptive-deploying-adodotnet-dev.html
So I added dbgen17.dll as a resource and a reference to policy.17.0.Sap.Data.SQLAnywhere.v4.5 (that also required Sap.Data.SQLAnywhere.v4.5.config)
Still throws the same connection error
Are there any other files it requires as additional resources? Can't find this information anywhere (no pun intended)
+++++++++++++++++++++++++++++++++ EDIT TO ADD MORE DETAILS +++++++++++++++++++++++
Connection string is like this
Public Function ReturnEng(HOAID As Integer) As String
Try
Dim ReturnString As String = ""
Dim vstrSQL As String = "SELECT Connection_Name FROM HOA_Connections WHERE Connection_ID = " & HOAID
Using Conn As New SAConnection
Conn.ConnectionString = HASConString
Using vCmd As New SACommand(vstrSQL, Conn)
vCmd.CommandType = CommandType.Text
Conn.Open()
ReturnString = vCmd.ExecuteScalar
Conn.Close()
End Using
End Using
Return ReturnString
Catch ex As Exception
EmailError(ex)
Return "Error"
End Try
End Function
Public Function ReturnDBN(HOAID As Integer) As String
Try
Dim ReturnString As String = ""
Using Conn As New SAConnection
Conn.ConnectionString = HASConString
Using vCmd As New SACommand("SELECT Connection_String FROM HOA_Connections WHERE Connection_ID = " & HOAID, Conn)
vCmd.CommandType = CommandType.Text
Conn.Open()
ReturnString = vCmd.ExecuteScalar
Conn.Close()
End Using
End Using
Return ReturnString
Catch ex As Exception
EmailError(ex)
Return "Error"
End Try
End Function
Public Function ReturnHOST(HOAID As Integer) As String
Try
Dim ReturnString As String = ""
Using Conn As New SAConnection
Conn.ConnectionString = HASConString
Using vCmd As New SACommand("SELECT Host_Name FROM HOA_Connections WHERE Connection_ID = " & HOAID, Conn)
vCmd.CommandType = CommandType.Text
Conn.Open()
ReturnString = vCmd.ExecuteScalar
Conn.Close()
End Using
End Using
Return ReturnString
Catch ex As Exception
EmailError(ex)
Return "Error"
End Try
End Function
Public Function ReturnConnString(HOAID As Integer) As String
Try
Dim vConnString As String = "eng=" & ReturnEng(HOAID) & ";dbn=" & ReturnDBN(HOAID) & ";uid=MyUserName;pwd=MySecret;CommLinks=tcpip(host=" & ReturnHOST(HOAID) & ");CommBufferSize=4000;PrefetchBuffer=8192"
Return vConnString
Catch ex As Exception
EmailError(ex)
Return "Error"
End Try
End Function
asked
04 Jan '17, 14:49
gchq
321●26●29●36
accept rate:
28%
What is your server command line and what is your connection string that you are using?
Added more detail above.
Ok, that took a bit of work to find the actually connection string details! ... And what is your server command line? E.g. do you start dbeng17 or dbsrv17 ? what other command line options do you use?
Sorry probably over-complicated that :-( Server starts using a batch file with line one
followed by all the other DB's
If we use the V4 assembly (iAnywher.Data.SQLAnywhere.v4.0.dll) it will run fine locally and connect to both v11 and v12 servers. At a pinch I suppose we could write a script to see if it's running in debug (local) or not and point to a different version of the dll, but that could cause more problems than it solves
My guess is that you are missing dbrsa17.dll which is a new deployment requirement
Here is the deployment documentation for the SQL Anywhere 17 .NET Data Provider:
http://dcx.sap.com/index.html#sqla170/en/html/815bcac16ce210149887de04eabb7343.html*loio815bcac16ce210149887de04eabb7343
Hey Chris
There is a typo in my original question - I added
dbcon17, dblgen17, dblib17, dbrsa17 and msvcr100 to resources.
Dave
What is the exact text of the error message?
What port is the server running on? You've specified the server option -sb 0 so it has to be 2638 or you must specify the actual port number in the connection string.
You also said "If we use the V4 assembly (iAnywher.Data.SQLAnywhere.v4.0.dll) it will run fine locally". Are you saying that v4.0 works and v4.5 doesn't on the same client compputer? That might be a versioning issue - the build number factors into this. I usually simplify this by running "setupvspackage /ua" and then "setupvspackage /i /v 4.5". I then check any "app.config" for misconfigured version/build (for example, Version=12.0.1.3351 when the build is 3359).
"Locally" might mean that a shared memory connection is working, but that TCP/IP connections are not!
Error message is
Running on the standard port - the same connection string happily connects to both v11 and v17 servers using the 4.0 provider.
Yes - v4 runs fine and connects to all servers - v4.5 doesn't from the same box, but works fine if deployed on a web server. If it was a versioning issue one would think it would throw the same error when deployed.
It would, of course, be nice to debug the app locally but it's not a complete game stopper. Our connection string specifies a connection over TCPIP and the host
When an attempt to use the 4.5 provider fails, what is registered in machine.config? What is in the GAC? In other words, have you used setupvspackage?
When you switch versions in your Visual Studio project, do you remove a v4.0 provider reference and replace it with a v4.5 provider reference? Do you use an app.config? Do you change your .NET target version to 4.5?
As far as the provider itself, there is essentially no difference between the v4.0 code and the v4.5 code. The two versions are just built differently.
Is this Asp.Net? Have you seen this MSDN forum posting: Unspecified error (Exception from HRESULT: 0X80004005 (E_FAIL)) has occurred: while creating new web application?
Generally we have a lot of legacy apps (web service and web site) that were built with .NET 4.0 - the sites used WebForms. Newer web sites use MVC. Whilst we are still building some MVC apps we rebuilt the .NET 4.0 sites to 4.6.1, fixed some bugs and deployed them in new Server 2016 boxes. Web service we built from scratch with 4.6.1 and the 4.5 dll - as web service applications are inherently difficult to debug locally they were deployed and tested before switching the service URL in the WPF application that uses it - older versions of the WPF app point to the existing web service on Server 2018 R2
Rebuilt apps using the 4.5 dll have the same issue with new MVC apps - work when deployed, but not locally.
The local machine does have sqla11 installed and that might well be causing the issue, but the connection string does specify which host, and has no problem finding sqla17 with the 4.0 provider