Issues setting up new datasource after 4.5.2.018 update - Bug or just me?

dev google-group-archive
1

I’m baffled here…

I have a server running Lucee 4.5.2.018 final

It currently has a working mssql2008 data connection to

*\dataserver\Instance1 aDB *

using a sql user (cfuser) & pwd on a non standard port

I recently applied 2.018

I am now trying to set up a connection to

  • \dataserver\Instance2 anotherDB *

using a the same user/pwd scheme

However when I try to create the dsn in Lucee I get

Cannot open database “mydata” requested by the login. The login failed.
ClientConnectionId:

server\instanceName, Uname, passwords, ports, firewall are correct.
\dataserver\Instance2 anotherDB IS accessible from my ACF8 instance

even the copy & paste window seems to be correct

connectionString:
‘jdbc:sqlserver://dataserver\instance2:XXXX;DATABASENAME=mydata;sendStringParametersAsUnicode=true;SelectMethod=direct’
, username: ‘cfuser’ , password:

Looking at the application log on the server I see the following error

*Login failed for user ‘cfuser’. Reason: Failed to open the explicitly
specified database ‘mydata’. *

however the error source shows it’s coming from MSSQL$Instance1 not MSSQL$
Instance2

Nowhere in the new data source set up am I specifying Instance1 and yet it
seems Lucee is trying to connect to it. There is no DB named mydata in
instance1 which is the source of the error.

It seems that it’s only taking the instance that was already set up and
ignoring new instance connections.

Am I just being an idiot or is this a bug?

2

*Login failed for user ‘cfuser’. Reason: Failed to open the explicitly
specified database ‘mydata’. *

however the error source shows it’s coming from MSSQL$Instance1 not
MSSQL$Instance2

Nowhere in the new data source set up am I specifying Instance1 and yet it
seems Lucee is trying to connect to it. There is no DB named mydata in
instance1 which is the source of the error.

Don’t use instance nams or dynamic TCP ports. Instead, set your second
instance to use a distinct static TCP port and connect the DSN in Lucee to
that port.

JochemOn Thu, Dec 17, 2015 at 5:54 PM, Jay B wrote:

–
Jochem van Dieten
http://jochem.vandieten.net/

3

Thanks Jochem,

Not using dynamic ports and can’t change the ports for the instances
without causing havoc to other applications.

But really…unless I’m doing something stupid…this has to be a bug no?On Thursday, December 17, 2015 at 11:11:10 AM UTC-7, Jochem van Dieten wrote:

On Thu, Dec 17, 2015 at 5:54 PM, Jay B wrote:

*Login failed for user ‘cfuser’. Reason: Failed to open the explicitly
specified database ‘mydata’. *

however the error source shows it’s coming from MSSQL$Instance1 not
MSSQL$Instance2

Nowhere in the new data source set up am I specifying Instance1 and yet
it seems Lucee is trying to connect to it. There is no DB named mydata in
instance1 which is the source of the error.

Don’t use instance nams or dynamic TCP ports. Instead, set your second
instance to use a distinct static TCP port and connect the DSN in Lucee to
that port.

Jochem

–
Jochem van Dieten
http://jochem.vandieten.net/

4

Yes. But I think the former is more likely than the latter.

netstat -ano is your friend to find out whether you configured everything
correctly.

JochemOn Thu, Dec 17, 2015 at 7:20 PM, Jay B wrote:

But really…unless I’m doing something stupid…this has to be a bug no?

–
Jochem van Dieten
http://jochem.vandieten.net/

5

Did the update again this morning with the same results.

Update: Rebooting the vm cleared this up. All datasources work as expected
now.

6

Alright…so sort of stupid me…but also stupid ACF admin…Lucee admin
was just doing what it was told.

I was copying the settings from ACF for the instance2 DB.

which were

Database anotherDB
Server dataserver\Instance2
Port 2849

However, after checking Instance2 is actually running on 2949
Now since this datasource has been working just fine for at least 3 years
with the wrong port specified, it seems that ACF admin looks at server for
an instance name and if found ignores the port setting. If you don’t
specify the instance, it uses the port.

Lucee does what it should and uses the port I specified (2849)…which was
the port to instance1…hence the error.

Dropping the instance name and using the correct port (2949) allowed me to
create the DSN.

Which is basically what Jochem said…but I needed to discover the typo &
weird behaviour in ACF admin before I could solve the thing.

7

I had a similar problem updating to 4.5.2.018 from 4.5.1.000 a few weeks
ago. After the update the connections I had to a SQL Express db no longer
worked. I haven’t had time to actually look into the error, so I rolled
back to 4.5.1. Did the update again this morning with the same results.On Thursday, December 17, 2015 at 10:54:24 AM UTC-6, Jay B wrote:

I’m baffled here…

I have a server running Lucee 4.5.2.018 final

It currently has a working mssql2008 data connection to

*\dataserver\Instance1 aDB *

using a sql user (cfuser) & pwd on a non standard port

I recently applied 2.018

I am now trying to set up a connection to

  • \dataserver\Instance2 anotherDB *

using a the same user/pwd scheme

However when I try to create the dsn in Lucee I get

Cannot open database “mydata” requested by the login. The login failed.
ClientConnectionId:

server\instanceName, Uname, passwords, ports, firewall are correct.
\dataserver\Instance2 anotherDB IS accessible from my ACF8 instance

even the copy & paste window seems to be correct

connectionString:
‘jdbc:sqlserver://dataserver\instance2:XXXX;DATABASENAME=mydata;sendStringParametersAsUnicode=true;SelectMethod=direct’
, username: ‘cfuser’ , password:

Looking at the application log on the server I see the following error

*Login failed for user ‘cfuser’. Reason: Failed to open the explicitly
specified database ‘mydata’. *

however the error source shows it’s coming from MSSQL$Instance1 not
MSSQL$Instance2

Nowhere in the new data source set up am I specifying Instance1 and yet it
seems Lucee is trying to connect to it. There is no DB named mydata in
instance1 which is the source of the error.

It seems that it’s only taking the instance that was already set up and
ignoring new instance connections.

Am I just being an idiot or is this a bug?

8

Just re-rebooted then VM and still having the same issue.On Friday, December 18, 2015 at 6:42:22 AM UTC-7, Mike Henson wrote:

Did the update again this morning with the same results.

Update: Rebooting the vm cleared this up. All datasources work as expected
now.