I just wanted to put the finishing touches on the resolution for this incident in the event that other customers experience the same problem.
As previously noted, the admin script was reporting that the .htaccess file had been updated for password protection when in fact it had not. Or should I say that it was updating exactly as it should, but was protecting the wrong directory. Confused ---let me explain.
Alex suggested contacting the Host and having the .htaccess enabled for the CGI_BIN directory. The problem is that most support folks are going to try and tell you that it is enabled and that the script is malfunctioning. To me it was obvious that this is a very professional script and enabling .htaccess on Apache is pretty much a no-brianer so I really couldn't buy in to the fact that the script was having a problem even though 3 high level techs at one of the largest Hosting companies in the world made that conclusion after trying to get it working for 18 hours.
Fortunately for me I have root access to my server so I was able to determine exactly where the problem was and make the necessary modifications.
To start, you will know if this is going to be an issue for you if you are running on a UNIX box configured with Apache and your CGI-BIN directory is located above your web directory --- that is --- it is not accessable from your website (except maybe through an FTP program, Telnet, or SSH) and is the only directory that you can execute CGI scripts from. When you install scripts to this CGI-BIN it is then executed in the visitors browser by simply typing an address such as http://www.yourdomain.com/cgi-bin/admin/admin.cgi. What is actually occuring is that your CGI-BIN is being aliased in the Apache configuration files with a command such as "ScriptAlias /cgi-bin/ /usr/local/www/yourdomain.com/cgi-bin/." This command is most commonly located in the httpd.conf file, but may also reside in the defaults.conf or any other configuration file that is being called by the httpd.conf file.
OK --- at this point you have a few choices, but obviously a .htaccess file is not going to work since it is protecting the CGI-BIN directory above www, not the CGI-BIN one being executed via the browser below the www level.
What I decided was that I would enable CGI scripts to be executed from anywhere within my website, but still maintain Alias Scripting to use for less secure scripts. Any script, such as Links SQL, that utilizes .htaccess to protect the admin files is pretty darn secure and I don't have a problem whatsoever placing it in a CGI-BIN directory under my www directory.
To allow CGI scripts to be executed from any directory of your website you need to find the command "AddHandler cgi-script .cgi" which is typically in the defaults.conf file or, once again, may reside in the httpd.conf or other specified Apache configuration files. If you have not been able to execute CGI scripts from any directory then this line has obviously been commented out since it is always present in the standard Apache set up files. Uncomment the line, restart Apache and re-install Links SQL in the directory of your choice. Just make certain that it is not an aliased directory.
I obviously know that most of you do not have root access to your server and will not be able to perform these steps, but when your Host is sitting there scratching their "you-know-whats" for three days, while swearing that Links SQL is to blame, you can print this post out and read it back to them. They should be able to correct this problem within two or three minutes.
If this helps just one person from going through what I did then it is all worth it.
Sincerely,
Charles