Hi David Based on the amount of users accessing the site, there is a possibitity that php_mssql.dll not being thread safe could be the problem. The only way to verify this is to use PHP as a CGI, run Apache as a multi-process server, or replace php_mssql.dll with php_odbtp_mssql.dll. As much as I like PHP and dislike Microsoft, I personally would not have used Apache/PHP on a Win32 platform to connect to SQL Server. The proper choice should be IIS/ASP.NET. I believe that IIS supports the single sign-on feature for intranet purposes. You may have to decide which of the solutions I have mentioned is the most feasible. -- bob On Fri, 19 Mar 2004, david wrote: > Thank you, Bob, for your continuing comments. > > The intranet site is used by approximately 100 people, and sees a good > amount of traffic every day. I don't really have an exact number of daily > queries that are executed, but it has to be a pretty sizable number, since > the site handles much of the business issues. > > The query in question fails randomly (as far as I can tell: I have been > watching for patterns for some time now.) If it always failed, that would > really help. Sigh. Random. Naturally. Worse, the query is 100% dynamic, and > built by the users (but of course they do not know they are building a > query. They are just selecting things to report on, which is the way it > should be, in my opinion). So, I don't have a query I can show as always > fails, or sometimes fails. > > The only common thread in all of this is the tables in question. There are > only a couple of tables, and they are used in the datawarehouse for > reporting. Oddly, though (and I cannot prove this as much as I would like > to) I think that some of the failures happen when no one else is using that > table. All the other intranet tables perform as expected (and there are a > LOT of those). > > I will look at the Apache 2/multi-process question. It is a great thought. > > I have another problem (this one is more of a how in the world do I do that, > and relates to digging out the user signed onto the workstation for a single > sign on solution: we won't go into the "is that a good idea" question, > because it is moot, and I came out on the losing end); apparently I can't do > this with Apache 2 and Windows, and so, long story short, perhaps I should > consider other web server options. > > Thanks, Bob! > david > > "Robert Twitty" <rtwitty@xxxxxxxxxxxxxxxxx> wrote in message > news:Pine.GSO.4.44.0403191029450.4935-100000@xxxxxxxxxx > > Hi David > > > > Do these few queries ALWAYS fail, or just occasinally fail? Is this > > intranet site used by many people? If the same query always fails, you > > can determine if it may be a thread-safe issue by running that query > > outside of Apache as follows: > > > > c:\php\php thequery.php > > > > If the above fails, then it is probably not due to the fact that the mssql > > extension is not thread safe. If it does work then it could be the > > problem. I am not familiar with Apache 2.0, but I do believe it is a > > multi-threaded server, which is not good for extensions that are not > > thread-safe. If Apache 2.0 cannot be configured to run as a multi-process > > server, you should consider using Apache 1.3. > > > > -- bob > > > > On Fri, 19 Mar 2004, david wrote: > > > > > Ah....thread safe. > > > > > > THAT is an interesting thought. Especially because I somehow suspect > that my > > > problem is related to the database and/or table being locked just when I > am > > > trying to read it. > > > > > > However, I have to profess some ignorance about FastCGI. I looked at the > web > > > site for it, but I am not sure if by installing it I am now magically > > > thread-safe? Or, once installed, do I need to make some code changes? > > > > > > My environment is an established intranet (Windows based; Windows 2000 > > > server, Apache 2.0; connecting over the network to MS SQL Server, also > > > running on Windows 2000). What is odd is that there are only a couple of > > > queries that fail, and when they do, they ONLY fail against certain > tables > > > used for reporting from a data warehouse, and then only now and then > > > (perhaps once a day; maybe less). The queries are dynamic in nature, and > can > > > pull data of integer, char, or varchar. All other queries (and there are > a > > > rather lot of them) for doing the mundane intranet stuff work perfectly, > and > > > have NEVER failed. It is a real puzzle. > > > > > > Thanks! > > > david > > > > > > "Frank M. Kromann" <frank@xxxxxxxxxxxx> wrote in message > > > news:10796513604800000@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > > Hi David, > > > > > > > > You problem might be a thread safty issue. the MSSQL extension is not > > > > thread safe (caused by the Microsoft Library used to create the > > > > extension). Use CGI or FastCGI to avoid this problem. > > > > > > > > - Frank > > > > > > > > P.S. I don't have the full thread of this discussion so I might miss > some > > > > important information about your setup. > > > > > > > > > Bruno: > > > > > > > > > > I did that. I had to wait a bit until it failed again, whcih it did > a > > > > few > > > > > moments ago. Alas, there is not one thing out of the ordinary in the > > > > log. > > > > > > > > > > Any other suggestions? > > > > > > > > > > THANK YOU! > > > > > david > > > > > > > > > > "Bruno Ferreira" <blueroom@xxxxxxxxxxxxxxxx> wrote in message > > > > > news:405882ED.80803@xxxxxxxxxxxxxxxxxxx > > > > > > david wrote: > > > > > > > > > > > > >Hello there! > > > > > > > > > > > > > >I have just about driven myself crazy with an odd intermittent > > > > problem. > > > > > > >[snip] > > > > > > > > > > > > > > > > > > > > > > > > > > I'd first start by turning on all logging I could in the SQL > > > > server > > > > > > so that I could see what's happening straight from the horse's > > > > mouth... > > > > > > > > > > > > Bruno Ferreira > > > > > > --- > > > > > > [This E-mail scanned for viruses by Declude Virus] > > > > > > > > > > > > -- > > > > > > PHP Database Mailing List (http://www.php.net/) > > > > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > > > > > > > > > > > > > -- > > > > > PHP Database Mailing List (http://www.php.net/) > > > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > > > > -- > > > > PHP Database Mailing List (http://www.php.net/) > > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > > > > > -- > > > PHP Database Mailing List (http://www.php.net/) > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > > -- > > PHP Database Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > PHP Database Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
