SQL Server Database Connection Problems

[peteconway]

{dialog.object}.populateControlsFromTable().

two things - does this control know about the new connection string, also beyond build 8099 new parameters were preset for callback, it may be your server is not responding in time and the populateControlsFrom Tables fails - you may want to turn on the debugging option of the action.

[StephenP]

So using {dialog.object}.populateControlsFromTable() is correct for loading data into the UX fields (say, after a lookup). But since I corrected my earlier problem, it seems none of my UX's like to update using {dialog.object}.populateControlsFromTable(). Do I have to rebuild all of these UX's? I've tried everything I can think of to update things (edit/save server-side scripts, etc.), but nothing is working.

[StephenP]

OK, I changed the AlphaDAO strings in my publish profile to use the local instance. We can now get into the system, and most things work. But I have one UX component with a repeating section that just won't work. But I also see that I was using {dialog.object}.populateControlsFromTable() to populate the repeating sections, so maybe that's causing problems.

[madtowng]

Between windows and mssql we are talking about microsoft. Never underestimate the power of a reboot.

[peteconway]

If the ticket doesn't get a response - call them. - I like them, used them years ago, they know their stuff. - BUT if 'The AlphaDAO strings are set (as they always have been) to the IP address of that machine.' - as you say - you don't need an IP address in the connection string as you are already on the same server you just need the SQL instance name.

[peteconway]

Possible - but ask them.

[StephenP]

We have a ticket in to Zebrahost.

The only thing I did out of the ordinary the day it broke was try to publish my first component to the server using http publish. It was going to a different directory on the same webroot, which is what I thought the model was. Is it possible that publish changed something? It seems unlikely, but I don't really know.

[peteconway]

Ask Zebrahost it is their server being used by you - they control it.

[iRadiate]

Check the server port is correct and/or try a different port .. maybe something else is using that port? Just a thought.

[StephenP]

The SQL Server and AA server are loaded on the same machine. The AlphaDAO strings are set (as they always have been) to the IP address of that machine. It is a Zebrahost server. So I don't see where firewall issues would be affecting it.

[christappan]

It could be a firewall or network issue? Assuming the IP address and credentials are still okay on the application server, you could try to ping the IP from the command line. If your server can't reach the database server, it's a firewall or network issue with one of the servers.

[StephenP]

I have been getting the following error today in any location where AA tries to access my SQL Server data. Any ideas what may be causing it? I can access the SQL Server data via the development server, so what am I missing on the live server?

Error: Could not connect to database.
Reported error: Database API specific error Your database has returned the following error code and description to Alpha Anywhere. Consult your database documentation for further information. 53 - '[Microsoft][ODBC Driver 13 for SQL Server]
Named Pipes Provider: Could not open a connection to SQL Server [53]. SQL State is: 08001 [Microsoft][ODBC Driver 13 for SQL Server]
Login timeout expired SQL State is: HYT00 [Microsoft][ODBC Driver 13 for SQL Server]
A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online. SQL State is: 08001'