Bob: I shall experiment with option #3 (replacing php_mssql.dll with php_odbtp_mssql.dll). This will take a couple of days (I want to test it all out...sigh...testing...) and then slip it into production. I will report back on the results. On the Single Sign On... I am happy to talk about (and would LIKE to) but I don't know that this is the proper newsgroup for it? I am open for suggestions? I brought the SSO question up in comp.lang.php awhile ago, and although there was some discussion, mostly it petered out rather quickly. PHP for me was a requirement (part of the intranet is some PHP modules which are used on LAMP platforms); that is why we went PHP/Apache. (.NET was never in the picture, although in hindsight, I wish we had put up IIS/PHP.) However, it is a stable platform, and with just two exceptions (one being the above!) and the SSO issue that has recently surfaced, the platform has not experienced a single glitch. Personally, I do not favor the SSO solution, but I understand the business drive for it. Security and convenience are often strange bedfellows, and don't always get along. You are correct in the IIS supports SSO. david "Robert Twitty" <rtwitty@xxxxxxxxxxxxxxxxx> wrote in message news:Pine.GSO.4.44.0403191304110.8686-100000@xxxxxxxxxx > 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 > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
