Could not find the ColdFusion component or interface secure.common.getreqstatus

[Guest]

I had a similar problem about a year ago (Re: It used to work and now it doesn't).   The quick and dirty solution was to create the secure.common directory in the calling directory.   This time, that doesn't work.  I am at a loss as to what to do.  I am running CF10 on a Windows Server 2008.

[WolfShade]

Do you have a "this.mapping" set in application.cfc that points to /secure as the location of components?

this.mapping["/secure"] = ExpandPath('/') & "/secure";

reqstatus = createObject("component","secure.common").getreqstatus();

HTH,

^_^

[Guest]

I am a CF novice, but it appears they do that for the root directory/secure in application.cfc    The more detailed createObject is in each place where the routine is called.   I hope that answers your question.

[WolfShade]

Hmmm.. well.. it's a Windows server.. when was the last time it was rebooted?  Let it run too long and buffers can fill or become corrupt, certain files can become so fragmented that the computer spends more time seeking data than actually using it.

Just a thought.

V/r,

^_^

[Guest]

I believe you solved my problem by having me check application.cfc.   It seems the wrong one was loaded up and it points to another directory.   Fixing that fixed another minor error I was having but the one I've posted about still exists.   Am I to assume that if the CF server is rebooted, this could solve my problem?

[WolfShade]

I can't guarantee that.  I'm just reaching for possible solutions.  I do know from _my_ experience that sometimes the server needs to be reboot (or quite often needs to be shut down for thirty-ish seconds and powered back on.)

Unless the server is in a high-demand environment, there's a 98% chance that it won't _hurt_ anything by rebooting/powering down.  But if the server has been on 24/7 for the last five years, powering down would not be a good option, as the hardware (power supply, CPU fan, etc.) might revolt and kill the server.

Just my two cents.

V/r,

^_^

[Guest]

This is a government computer, in a government data center.   They are running VM and have 50 or so applications/databases set up; my application is one of them.  They are scheduled to reboot the end of the month.  It all depends on if my customer can wait until then.   Thank you.

[WolfShade]

Understood.  I work for US DoD. 

[Guest]

I worked for IBM for 30 years; 25 of those as a Navy contractor.  Then with a small company as an NRO contractor.  Then when that contract died, with another small company as a DIA contractor.  That was the 1st place I dealt with machines I wasn't in control of.  Very frustrating experience.  This stint as an AF contractor has been the worst.

As for the reason this thread is here: I found that I had an application.cfc pointing to my development machine instead of the Test machine.  Correcting that solved one problem, but this one is still plaguing me.  Do you think a reboot of the Test CF server would solve the issue?   I hesitate because of the wad of red tape I have to go through to get it done...   that and the SysAdmin stating he has 50 other applications that run fine and don't have the issues mine does.  As I said, frustrating.

[WolfShade]

If the SA is insisting that other apps are running fine on the same server, then rebooting probably won't make any difference.

And, yeah, I understand about submitting paperwork for an ASI.  Never fun.

The only other suggestion off the top of my head is to go through every line of Application.cfc with a fine-toothed comb and make sure (triple check) that everything is pointing to the right machine, right folder, etc., and that everything in CFAdmin is as it should be.  For something to work with no issues for a long time, then suddenly develop a chronic issue, something changed, somewhere.

HTH,

^_^

[Guest]

I can check the application.cfc again...   as for CF Admin, the SA has control of that.  I'd have to get him to get me a screen shot.   Thanx!

[Guest]

Something strange is going on.   I was looking for the places where the datasource was spelled out.  The only place was in application.cfc.  I changed it and the CF trace displayed the correct database when I log into the application.  However, when I select an option, the queries in the trace show the previous database.  I cleared cache, but nothing fixes it unless I go into the .cfm file (for the option) and change all references of #datasource# to the actual literal database name.  When I do that, it shows up correctly.  The assignment in application.cfc is:

<cfset this.datasource="MyDatabase">

Thanx.

[WolfShade]

Change all references to #this.datasource# instead of #datasource#.  According to this SO post, THIS is not included in the automatic order of scope search when looking for a variable.

And honestly, something like that should be in the request scope, anyway, IMHO.

HTH,

^_^

[Guest]

I changed all the instances of #datasource# to #this.datasource" .  The CF server had its scheduled reboot last night.  This morning I get: "Element DATASOURCE is undefined in THIS."  Application.cfc has this: <cfset this.datasource="MyDB">

What am I doing wrong?

[WolfShade]

I am going to assume that all of your THIS properties are set immediately below the opening CFCOMPONENT tag in application.cfc.

If you take a page (any page) and the first line add <cfdump var="#this#" />, does it give you a dump of everything in the THIS scope?

V/r,

^_^

[Guest]

.   I don't think I'm doing it correctly.  Here's the output.   I also notice that before I log in the datasource is correct (wedtprod2).  When it gets to the main screen, CF Admin debug shows me the datasource is incorrect (wedttest).   Not really sure what is going on.  I used AstroGrep to go through all the code and cannot find the wrong datasource anywhere.  At first I searched all cfc and cfm files and got nothing.  I changed that criteria to *.* and found a settings.xml.  I changed it and there was no change in the CF Admin debug output.  Obviously I have messed something up.

[WolfShade]

Well, we have at least determined that datasource does, indeed, exist in the THIS scope.

However, I still think that datasource names should be defined in the request scope.

In application.cfc, try removing the datasource from THIS and push it into REQUEST; then changing the "datasource='#this.datasource#'" to "datasource='#request.datasource#'" for your queries.

And I have (in the past) run into scenarios as you describe whereby at one point a variable contains correct information, but at another point it does not.  CFTRY/CFCATCH might help track that down.

V/r,

^_^

[Guest]

I was able to put <cfset this.datasource="wedtprod2"> as the 1st line of the files in one of the options and was able to correct the datasource, but I thought setting it in application.cfc did it for me.  So confused.

[Carl Von Stetten]

If you set this.datasource = 'somedatasourcename' in your Application.cfc pseudo-constructor (the part between the <CFCOMPONENT> tag and the first <CFFUNCTION>), all queries that don't have the "datasource" attribute set will automatically use the datasource defined in Application.cfc.  However, if your application uses more than one datasource, then you have to specify the correct datasource name in each <CFQUERY> tag.  You could put the most widely used one in the this.datasource in Application.cfc and simply omit the "datasource" attribute from those queries, and then specify the "datasource" attribute for queries that use a different datasource.

[Guest]

Here's snippets of what I have:

<cfcomponent>

<cfset this.datasource="MyDB">

<cffunction

name="OnApplicationStart"

access="public"

returntype="boolean"

output="false"

hint="Fires when the application is first created.">

<cfset application.datasource="MyDB">

</cffunction>

</cfcomponent>

Is the application.datasource messing me up?

[WolfShade]

LouieWarren wrote:

Is the application.datasource messing me up?

Highly unlikely.  Although I must admit that I cannot think (off the top of my head) of what might be causing the issue of the old DSN appearing after changing it to the new DSN.  Unless (for some reason) when you save the files you're not saving it to the server.  That's the only thing I can think of.. right now..

HTH,

^_^

[Guest]

I may not have explained this correctly....

I have one Oracle database.   One user/schema is database1  and one is database2.  The code base for the old application exists in one directory on the same VM server.  The code base for the new application exists in another directory on the same VM server.   In CF admin, the old application points to old code base/database1 and the new application points to new code base/database2.   The gov't DBA suggested this as the easiest way to set something up for the customer to play with and eventually bless (or not) to production.   I'm thinking that may have been easy, but is causing me headaches now.

[Guest]

In an attempt to brute force it, I removed all assignments to #this,datasource# to the actual name of the datasource in double quotes.   It worked on all the options,except the one that was giving me the error message that started this whole thread.   Now when I select that option I get a 500 internal server error and nothing in the debug or other error message.  Can I use <cfdump /> to get the details.  Once again sorry for being dense.

[WolfShade]

CFTRY/CFCATCH/CFDUMP should provide you with at least what is causing this to happen.

V/r,

^_^

[Guest]

Thanx!  That's what I needed.  I just need to read up on how to use them to get the most info.  My CF skills are few.  Thanx again!