Skip to main content
Inspiring
April 18, 2025
Answered

Our site works fine elsewhere but not here

  • April 18, 2025
  • 1 reply
  • 606 views

We are stumped ... we've been creating a CF web site for years.  It works fine on all our coders localhosts and it works fine on a commercial CF hosting server.  

 

We just copied all the code into a rack WE own and it simply will not work.  

 

The errors we're getting are db errors.  Table xxx does not exist yet we can see it on our RDP screen.  

 

We've triple checked our settings in our CF Admin console ... 

 

In 28 year of using CF we've never encountered this.  We have cleared our cache ... rebooted our CF server and db server and it still insists it cannot find a table or a field within a table. 

 

We're using an old version CF 2018.  On locals and at our commercial CF hosts.  

 

What (more) clues can I provide to help us fix this.  We're about to throw the rack in the bin. 

 

Many thanks in advance. 

 

    Correct answer robertd69433945

    That will be great to hear if you solved it. 

     

    And of course the suggestion I offered wasn't a solution but a diagnostic tool to hopefully help get us there. I love helping find ways for folks to not have to regard cf merely as a black box. 

     

    If things do remain resolved, it might help others if you might clarify a bit more on what you may feel was the solution. Also,. I'd asked if you could let us know what db you're using, and whether this failing cf is still on cf2018 (you'd referred to the "others" as bring on that). 

     

    Finally, if it is resolved, it would also help if you marked both my first reply and then your final one as "answers", to help folks quickly connect the dots. 🙂 


    Using CF 2018 Developer. 

    But that's not relevant. 

    It's the db server that had the problem. 

    We were calling onto the correct server just within the db there there 3 different dbs?  

    We had selected the wrong one. Does that make sense?

    1 reply

    Charlie Arehart
    Community Expert
    Community Expert
    April 18, 2025

    First, pause and take a deep breath. 🙂 No need to throw anything away. There's ALWAYS an explanation for such a problem. It's new to you, and frustrating, sure. You just need to look at things differently than you ever had to. 🙂 Maybe we can offer that objective perspective.

     

    So first, since the cfquery IS connecting to the db but just not liking your table name, there are many questions we could ask/have you verify (about the username used in the dsn, possible dsn config issues, possible db server config issues, etc)

     

    But let's start more simply: use the cfdbinfo tag to ask it to show what tables are in that db for that dsn. You may find, for example, that it shows them with a schema name before the table. If you changed a test page to use that, and it works, then we could talk about options to set the schema name for you instead in the dsn or db config.

    <cfdbinfo
        type="tables"
        datasource="yourdsn"
        name="gettables">
    
    <cfdump var="#gettables#">

    And if somehow that doesn't help let us know what db you're using, and whether this failing cf is on cf2018. You only said the others were. 

    /Charlie (troubleshooter, carehart. org)
    Inspiring
    April 19, 2025

    I've done what you suggested and presume the dump that I get is indeed the list of the tables in our db.  

    Not even close. 

    For eaxmple one is even called tables

    There's a VIEW column that is not clickable. 

    Another it claims is called xml_schema_wildcards

    Neither of these exists in our db. 

    Yet when we look at our datasource list we are pointing to the correct 10 address in the rack and it's the correct db name.  

    The REMARKS column is always empty. 

    It's as if we're pointing to an entirely different db source. 

    db server config issues?

    We know the username and password are correct. 

    We also know that the database is VERY out of date and expected to either one by one make corrections or upload the entire db over again.  But when we start making alterations (updates) and they simply do not take ... it's as if we're editing the wrong db.  

    Very much appreciate your dump suggestion just wish we'd recognize more of the table name and less of them  🙂

     

    Robert

    Inspiring
    April 19, 2025

    Just ran this on my localhost and it whows all the tables correctly. 

    But then I ran it as procedures ... and it confirms that a SP is NOT there even though t can see it on my DB screen.  

    So we're obviously pointing to the wrong place yet the IP to get ot the db is correcct as is the db name correct.  

    You and I have worked together before ... and I'd sooner not pulically display some screen shots ... would you care to again?  I am in Europe.