SQL server licence error
Dear developers,
We have an existing ASP application that displays recordsets from a db based on user selection. The db is SQL server 2000 Service Pack 4 and the web server is Apache with Sun Chili Soft ASP. This application has been working fine for the last 3.5 years until now. I am getting a bizarre message saying that the chilisoft driver is for use only with ASP pages when the script executes the open command, as follows:
<%
set rstMain = CreateObject("ADODB.Recordset")
rstMain.Open "SELECT * FROM dres_main", "Driver={SQL Server}; Address=137.44.41.130, 1433;DATABASE=DRES;uid=(hidden);pwd=(hidden)"
Set rstMain = Nothing
%>
I get this message:
Error Type:
ADODB.Recordset.1 (0x80004005)
SQLState: HY000 Native Error Code: 0 [DataDirect][ODBC SQL Server Driver]The DataDirect ODBC driver you are attempting to access has been provided to you by %s %sSunChiliSoft for exclusive use with ASP. You are not licensed to use this driver with any application other than ASP. If you would like to purchase a driver for some other use, please call 800-876-3101 or visit DataDirect at www.datadirect.com
This error may be down to having installed the latest version of chilisoft but we haven't rolled back yet - it's a last resort. If anyone has any idea why I am getting this error I'd be very grateful.
AL
[1397 byte] By [
gargantua] at [2007-11-26 11:55:57]
# 1
Sounds pretty clear to me.
You have upgraded ASP (from which version?). The ODBC driver you have installed is from the old version and does not recognise the new version of ASP and so thinks you are using some unlicensed software which in effect you are.
I guess you need to upgrade the ODBC driver.
I don't think the new version comes with any drivers so you probably just need to create a new DSN using the standard microsoft ODBC driver.
Duncan
# 2
The issue might be to do with you copying odbc.ini from the previous asp server setup to the latest 4.0.2 one.
Please check your asp_server_root/asp-server-3000/odbc.ini file for some incorrect syntax. I would also recommend setting all DB config(s) from admin console to avoid issues like this.
Try to remove your DB setting and recreate them back in and test it with "Test Connection" from admin console.
You could also try manually changing odbc.ini:
Replace SQLServer_template with MSSQLServer_template(need server restart).
See a couple of threads related to mssql connectivity issue as well:
http://forum.sun.com/jive/thread.jspa?forumID=116&threadID=53254
http://forum.sun.com/jive/thread.jspa?forumID=116&threadID=53126
# 3
Thanks to everyone who replied to my message. we've now got it working by rolling back to 4.0.0.*. A desperate act and one that does not bode well for the future of inter UNIX-NT communication in our organisation. Seems like we will never be able to move to a new version of chili soft.
Just for info. We only ever use the gui to create DSNs, and the drivers were the old drivers anyway, but thanks for the suggestions.
You all rock!
# 4
Hi - I'm the techie behind the original post for this thead.
Due to other problems we have again tried to upgrade from 4.0.0 to 4.0.1. It works
for about 20 days (I did it Dec19th and it failed on Jan1st). Is there a license issue ? I
recall seeing a few posts saying that the latest version doesn't have a license anymore
but something is 'timing out' and giving this strange error ?
I tried a crude stop/start the casp daemons but it's possible that it's stored the original
install date in a file and is using this as an expiry ?
Help...
Paul
# 5
No real ideas....
Does it not work any more - are you saying a stop/start or reboot does not clear the error?
Not sure why it should run for 20 days, if its looking at a date from the old install then surely it would have failed straight away. Sounds a bit odd.
My only thought which is probably completely wide of the mark is do you have some sort of month end/month start procedure that has caused the problem. Just wondered with it running fine and then failing on the 1st, perhaps something daft as some old code that resets the dsn or odbc files for some long forgotten reason.
Duncan
