changed database passwords

[Kristin Gitler]

We recently had a need to change the database passwords for a couple of sites using CF8 Enterprise & MS Sql Server. 

We changed the passwords, reset the app pools, and at first, it seemed to be fine, but now we are having connection errors.  We cleared out the cfclasses folder and restarted CF, also  IIS.

 

We still can’t connect – what are we missing?

 

Thanks,

 

Kristin

 

 

[Ken Cameron]

It seems to me that on a Windows box the ODBC Manager seems to want to mirror what is in the CF connections profile. In theory you should be able to use one without the other, but I’ve found keeping the two in sync was the best stable answer. So checking that they are in sync would be my first step then testing them (ODBC) via something simple like an Access or Excel app.

 

-ken cameron

[Kristin Gitler]

I am able to connect from my laptop in SQL Mgt Studio using the datasource users, so I can connect outside of Cold Fusion using those user names – would that be the same kind of test? 

 

But I’ll have the host check that they are in sync.

 

Thanks,

 

Kristin

--
You received this message because you are subscribed to the Google Groups "Central New York ColdFusion Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cfugcny+u...@googlegroups.com.
To post to this group, send email to cfu...@googlegroups.com.
Visit this group at http://groups.google.com/group/cfugcny?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ken Cameron]

Yes, provided that is the same box. It seems the ODBC manager on a system tries to act as a universal gateway and when it has different user/password combos than CF I’ve had issues.

 

-ken cameron

[Charlie Arehart]

I’m curious, Ken: Kristin had mentioned using CF Enterprise and SQL Server. What led you to discussing ODBC? Is it that you maybe knew something about her environment already? Just curious.

Anyway, Kristin, you say you had to change some database passwords but are having connection errors.  Do you mean CF pages are running, and the CFQUERY tags (or the like) are failing? Always? Sometimes?

Also, you refer to app pools, but those (in IIS) would have nothing to do with CF-to-DB connections. Nor would the contents of the cfclasses folder (compiled, saved CFML class files). I realize you may be grasping at straws, trying (or open to) anything. I just want to suggest that those seem to be rabbit trails that wouldn’t seem productive.

If you’re having DB connection problems, the real next step is to better understand those. Is it on some pages? All pages? For instance, maybe you changed the DB username/password on the CF Admin datasource definitions, but then on some pages you may have provided the username/password attribute on a CFQUERY, so you’d need to change those as well. And if it’s not always, how often is it? Is it that one page may sometimes work and then sometimes fail? Finally, what’s the error message.

I sense that it seems to be a mystery, but usually there is a very clear explanation for any such problem. It’s just a matter of connecting the dots. Hope that’s helpful.

 

/charlie

 

From: cfu...@googlegroups.com [mailto:cfu...@googlegroups.com] On Behalf Of Ken Cameron
Sent: Friday, March 22, 2013 9:18 AM
To: cfu...@googlegroups.com
Subject: RE: [cfugcny] changed database passwords

 

Yes, provided that is the same box. It seems the ODBC manager on a system tries to act as a universal gateway and when it has different user/password combos than CF I’ve had issues.

 

-ken cameron

--

[Ken Cameron]

Charlie,

 

No I don’t know about Kristin’s setup, but was mentioning something I’d seen in the Windows environment. It seemed that the ODBC manager somehow was ‘following’ the setups of DB connections in the CF admin. And that I had seen issues crop up when a change was made in one that didn’t get reflected in the other. Just an annoying Windows thing I always thought.

 

 

-Ken Cameron Member JMRI Dev Team

www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com

www.syracusemodelrr.org

 

 

[Kristin Gitler]

Thanks Charlie,

I did finally get it working, but I honestly don't know how.  When we first changed them, it seemed to work - for maybe about 4 or 5 hours. Then it started to fail.  I did have a couple of old pages where the attribute was on the query, but I figured that out and changed those - once I did, those pages worked, but those that did not have the attribute on the query didn't work.  In the end, I messed around with the cached queries settings in the datasource set up, and I re-entered the passwords several times. Sometimes even though the datasource would verify (in cfadmin), the pages still didn't work.  I also set the application to expire at 0, renamed it (in Application.cfc) and reloaded it several times.  You're right, I was grasping at straws.  Basically it seemed that CF, or at least my applications, were not recognizing the changes.

What would have been the correct steps for changing the database passwords and having the applications recognize it? In the end, I got it to work, but just by dumb luck.  I did search around a lot, but found nothing on this topic - I suppose it's not something that is done very often, and I hope not to have to do it again!

Thanks,

Kristin

---

From: "Charlie Arehart" <charli...@carehart.org>
To: cfu...@googlegroups.com
Sent: Friday, March 22, 2013 11:40:53 PM

[Charlie Arehart]

Well, given that you mention cached queries, that could have been an issue. And given that you mentioned having code that DID have the username/password on the CFQUERY (which you removed), then if you use “trusted cache” (in the CF Admin Caching page), you may have had changed code in memory (in the template cache) that was not picked up when you changed it. Finally, if those tags were in CFCs whose instances you may have stored in a shared scope (application, session, or server), it could be that THOSE were not being changed with respect to the CFML file changes you were making.

So given all that, when you ask “what would have been the correct steps”, I’d propose (solely based on the above) that perhaps simply restarting CF could have helped. That would have, in one fell swoop, wiped out the query cache, the template cache, and the shared variable scopes.

I suppose it may never be an issue for you again, and perhaps you did do that (or perhaps you may have had reasons that you may have felt that you could not) but if perhaps this may help someone in the future, it seemed worth suggesting.

 

/charlie

PS And thanks, Ken, for your clarifications in reply to my other note on this thread.

[Kristin Gitler]

Thanks Charlie, the host did at some point restart CF, but that was after we had all the issues, I’m not sure at what point.  I should have thought of that early on (or the host should have), but I think I went into panic mode when it seemed to work at first, and then suddenly I had 2 sites down and hundreds of cferrors!

 

Thanks,

 

Kristin

 

 

From: cfu...@googlegroups.com [mailto:cfu...@googlegroups.com] On Behalf Of Charlie Arehart
Sent: Tuesday, March 26, 2013 11:14 AM
To: cfu...@googlegroups.com
Subject: RE: [cfugcny] changed database passwords

 

Well, given that you mention cached queries, that could have been an issue. And given that you mentioned having code that DID have the username/password on the CFQUERY (which you removed), then if you use “trusted cache” (in the CF Admin Caching page), you may have had changed code in memory (in the template cache) that was not picked up when you changed it. Finally, if those tags were in CFCs whose instances you may have stored in a shared scope (application, session, or server), it could be that THOSE were not being changed with respect to the CFML file changes you were making.

--