I agree, and that's why I said you were lucky. I work with databases that use the UNICODE data types nvarchar and ntext. Neither of these types are supported by DB-Library, and there are no local fixes. The odbc ext also does not support these types because it does not make use of the UNICODE version of the ODBC API. So, in order to continue using PHP, the odbtp extension had to be created. The use of the word "better" or "best" pertains only to odbtp's support for SQL Server within PHP, and not its ability to be used by a legacy system. However, I think you are underestimating the latter. It appears that you have convinced yourself that you will have to change your code without verification. Support for all of the mssql_* functions was added in ODBTP 1.1. While it was not possible to test it in every way imaginable, it did pass all of PEAR DB's tests for the driver written with the mssql_* functions. In the end it is your choice, especially since I will not be held responsible by your superiors if something goes wrong. However, don't knock it til' you've tried it. :-) -- bob > > Personally, I don't like the idea of having to change perfectly good SQL > > in order to work around driver imperfections. Anyway, good luck, and stay > > away from real, nvarchar and ntext fields, I wasn't as lucky. :-) > > > One should be careful using word as "best" and "better". > > Maximizing fitness (finding the best solution) is done by locating a > global maximum, it might be that odbtp is part of a global maximum, but > if one is at local maximum, then before one decides to go to the global > maximum, one need to look at the energy function to traverse from the > present local maximum to the global maximum. If this is high, and one > can find a another suitable local maximum close by with involves a > minimum of energy to reach then this local maximum can be consider a > better chose then the global maximum.Optimal solutions are sometimes > better than the best solution. > > In short, things are not black&white, but gray. :) > > On a more practical level: this is a situation every developer has to > face: should I take the time to replace the present, know to work, code, > with new code and a new API that will need the the entire machinery of > learning/writing/testing/debugging or should I make a fast, and > reliable, fix, that one know will work, and will solve the present > problem? > > Most developers will opt for the last solution, since it fix the problem > and (s)he can continue with the work that really needs to be done. > > > > > > -- bob > > > > > In any case, the problem was easy solved by the suggestion David gave. > > > > > -- > PHP Windows Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
