# The battle between users and developers - Thread: https://externals.io/message/38234 - Original archive: https://news-web.php.net/php.internals/38234 - Started by Lester Caine on 2008-06-15T06:54:36+00:00 - Messages: 12 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #38234 — Lester Caine — 2008-06-15T06:54:36+00:00 URL: https://externals.io/message/38234#38234 From Pierre > Playing off base. What I proposed you is to help us to get your > software continue to run smoothly with PHP, while keeping the windows > support. In the end you may even get a faster version on windows, but > I suppose you don't care about that (poor customers ;) . This I think is part of the current battle - and it is a battle - between those of us who use and spend a lot of our time SUPPORTING PHP use in the field. I came to PHP when PHP5 was in late beta, with RC's just coming out, and I actually release my first applications in early 2004 USING a late RC for the simple fact that I THOUGHT at the time it was going to be the way forward. I knew there was still a 'problem' with Unicode in PHP5 but the discussion even then was that this would be addressed in PHP6 - something that was then nailed down at that meeting in Paris in November 2005? Did I make the right choice going to PHP5 early? Well in hindsight probably not, because on the projects that I contribute to I have been - in my mind - wasting time fixing problems introduced by 'improvements' to PHP4 ever since. Since most USERS have never been convinced of the advantages of PHP5, until the plug was finally pulled on PHP4. I wish that PHP4 had been put into a security fixes only mode a year or so earlier, so we could have nailed down applications that work with the final release and got on to actually USING the improvements in PHP5 in the field. OK some projects who had a lot more developers split their projects and started PHP4 and PHP5 versions, but I obviously back the wrong horses :( Perhaps Interbase/Firebird is the same wrong decision, but I've been using that since the early 90's - long before web based working became the norm. Do my CUSTOMERS need a new tidied version of Array - NO - they have no idea what goes on under the cover. They all have a job to do and in many cases THAT has not changed in the last 20 years. Yes HOW they do it has changed, but essentially things like 'write a letter' are not using anything that was not available and perfectly functional 20 years ago. They have gained nothing by the cost of several upgrades to windows. In fact NOW they may not even be using a word processor at all, with simple form letters generated in web based applications. The very applications PHP is providing so nicely. None of my paying customers actually need Unicode, simple Ascii English is fine for them. The main reason I 'would like' to get away from the mess of code tables and character conversions is for the non-paying people who use the international projects that I help to develop. I have spent a lot of time making those projects compatible with all of the problems that changes to PHP4 and 5 have thrown at me and now I'd like to pin down a build of PHP5 that I can consider stable, get into security only mode, and get on to a version of PHP that is a simple flat field for multi-lingual text. Am I letting my customers down - *NO* - we are developing a number of enhancements to what they *DO* with their systems, while battling to fix the problems of 'improvements' to OS, Browsers, and even the Database engine. Yes, this compulsive requirement to keep changing things is even causing problems in the Firebird camp! Can I simply bury my head in the sand and ignore the newer versions of PHP5.3 - NO - because users of the projects I'm involved with will be complaining that something does not work. Heck we are getting bug reports for *PHP6* !!! To me open source is about cooperation. We all contribute what we can to the melting pot. Personally I spent two years as treasurer of the Firebird Foundation and only stepped down because a change in workload :( Windows does not make for an 'open' development process although I do understand that the major block of having to BUY a M$ compiler has been removed? If I had my way, I would only support Linux servers, and some of my 'windows only' customers are now ASKING for Linux when we need to upgrade server hardware! Do I have time to help develop PHP on Windows - NO. Would I find time if key parts are dropped - probably not. I had to find time when Borland announced that Interbase was being killed off in 1998. I had ten years of time invested in the products using it. I learnt one lesson, and 95% of what I am now doing is not dependant on product that someone else can wipe out. The current problem is the 5% that is and that code base is over 15 years old! It still does what the customers want perfectly so they are unwilling to change it, and I don't have time to do more than recompile things every time windows moves the goal posts. CURRENTLY - what is actually WRONG in PHP5? Look at the minutes of the 'PHP6' meeting http://www.php.net/~derick/meeting-notes.html - what has actually been addressed in coming up to 3 years? Can we answer point 1.1 yet - is the current logjam brought about by requiring an OFF switch - if PHP6 is unicode only internally can we move it forward, and keep PHP5 as the none unicode branch? Can't we learn from the 'mistakes' of PHP4 or are we still going to be waiting for PHP6 in another 3 years. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38236 — Lukas Kahwe Smith — 2008-06-15T07:09:16+00:00 URL: https://externals.io/message/38234#38236 · In reply to: #38234 > From Pierre > > […] > > This I think is part of the current battle - and it is a battle - > between those of us who use and spend a lot of our time SUPPORTING > PHP use in the field. I hope the purpose if this post was to vent .. and I hope that you are now vented. Aside from this you just wasted the time of anyone who has actually read your post, hoping that there would actually be some relevant content to read. Instead you can shouted, which several people have asked you not to do. Lester next time you are about to click "send" on a mail where you have capitalized entire words, please take a deep breather and hit deleted instead. regards, Lukas Kahwe Smith mls@pooteeweet.org PS: How about instead sending a mail to the firebird foundation, to which you seem well conntected, and see if they can help? --- ## #38237 — Lester Caine — 2008-06-15T07:50:31+00:00 URL: https://externals.io/message/38234#38237 · In reply to: #38236 Lukas Kahwe Smith wrote: > > > > > […] > > > > I hope the purpose if this post was to vent .. and I hope that you are > now vented. Aside from this you just wasted the time of anyone who has > actually read your post, hoping that there would actually be some > relevant content to read. Instead you can shouted, which several people > have asked you not to do. Lester next time you are about to click "send" > on a mail where you have capitalized entire words, please take a deep > breather and hit deleted instead. Partly to vent - see other post about finfo_open - this weekends waste of time! "It works fine here" from other developers is equally annoying when looking at a white screen without even an error message! But the main problem is getting some answers to what is happening to PHP6. I will continue to shout now since asking politely over the last couple of years has not achieved anything :( > regards, > Lukas Kahwe Smith > mls@pooteeweet.org > > PS: How about instead sending a mail to the firebird foundation, to > which you seem well conntected, and see if they can help? They have had the discussion and since the php_interbase driver *IS* working fine with Firebird since Ard produced the PHP5 version of it then there has been no requirement to replace Ard's effort. None of the people actively using Firebird on PHP can see the need to invest any time in PDO but because of the bugs introduced in the 64 bit linux builds of php_interbase we are trying to get some time invested into that. The core development work in FB has been unicode, and any work on the driver for PHP6 is stalled until there is something that can actually be done :( Two years ago I had a fully configured development setup for PHP6 on linux all ready to get stuck in. Since then I've lost a major source of funding and fixing some of the stupid little problems due to PHP upgrades is now an irritating delay to other more productive work. It normally takes hours to get into other peoples code to find out where the fault is even before you can start to find a fix! Having then to learn the insides out of the whole of the PHP code base to fix the actual bug is just impractical - and half the time the 'bug' is actually a pigging change to some functionality :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38238 — Lukas Kahwe Smith — 2008-06-15T07:55:52+00:00 URL: https://externals.io/message/38234#38238 · In reply to: #38237 > They have had the discussion and since the php_interbase driver *IS* > working fine with Firebird since Ard produced the PHP5 version of it > then there has been no requirement to replace Ard's effort. None of > the people actively using Firebird on PHP can see the need to invest > any time in PDO but because of the bugs introduced in the 64 bit > linux builds of php_interbase we are trying to get some time > invested into that. The core development work in FB has been > unicode, and any work on the driver for PHP6 is stalled until there > is something that can actually be done :( Ok, to spell it out one last time: If windows support cannot be provided in 5.3, there is a good chance that this will increase the likelihood that interbase driver will soon be out of PHP core, even if it still works on Linux. Also to remind you once again, our windows guy has gone missing and we are rebuilding things from scratch for 5.3. If this is not enough of a problem to fix, then so be it. If you continue to shout, then we have a good chance of being the first (or among a very small group of people) to be banned from this list. Though this is of course not my call to make. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #38241 — Lester Caine — 2008-06-15T08:40:40+00:00 URL: https://externals.io/message/38234#38241 · In reply to: #38238 Lukas Kahwe Smith wrote: > Ok, to spell it out one last time: If windows support cannot be provided > in 5.3, there is a good chance that this will increase the likelihood > that interbase driver will soon be out of PHP core, even if it still > works on Linux. Also to remind you once again, our windows guy has gone > missing and we are rebuilding things from scratch for 5.3. If this is > not enough of a problem to fix, then so be it. I've obviously missed something .... If there is a problem simply providing a windows build of PHP5.x then that is a different matter. Still not saying I can help - but I have already spent some time having another look at doing my own Windows builds. It looks like the same problem I have with my own Firebird builds though ... need M$ tools to do the job :( I have an older windows server that is running as backup at present which I could safely load some of the M$ stuff on - if it will work on W2k ..... But I'd prefer to stay inside my safety zone ..... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38242 — Lester Caine — 2008-06-15T08:50:27+00:00 URL: https://externals.io/message/38234#38242 · In reply to: #38241 Lester Caine wrote: > Lukas Kahwe Smith wrote: > > […] > > I've obviously missed something .... > If there is a problem simply providing a windows build of PHP5.x then > that is a different matter. > Still not saying I can help - but I have already spent some time having > another look at doing my own Windows builds. It looks like the same > problem I have with my own Firebird builds though ... need M$ tools to > do the job :( > > I have an older windows server that is running as backup at present > which I could safely load some of the M$ stuff on - if it will work on > W2k ..... OK fell at first hurdle :( Two notes on Windows Building from source page 1/ Links only work from IE Browser - or at least to get a download to start 2/ Express will only install on XP or Vista Both XP machines here have Builder Development suites I can't risk damaging :( > But I'd prefer to stay inside my safety zone ..... Back to doing this on cygwin ..... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38247 — Pierre Joye — 2008-06-15T10:22:56+00:00 URL: https://externals.io/message/38234#38247 · In reply to: #38241 hi Lester, > Lukas Kahwe Smith wrote: > > […] > > I've obviously missed something .... > If there is a problem simply providing a windows build of PHP5.x then that > is a different matter. > Still not saying I can help - but I have already spent some time having > another look at doing my own Windows builds. It looks like the same problem > I have with my own Firebird builds though ... need M$ tools to do the job :( What we actually need is not C developers or new core developers (well, we do but it is not a requirement here). We are missing tests (as in phpt which can be run using a firebird DB) and active users giving feedback and running these tests. If you can write tests (you and the PHP firebird community) and run them using our sources and binary releases, that will already do the job. That's all we need to keep the extension alive. > I have an older windows server that is running as backup at present which I > could safely load some of the M$ stuff on - if it will work on W2k ..... > But I'd prefer to stay inside my safety zone ..... We can take care of the builds and port the firebird clients libraries to Windows and/or MS tools. But we can do it only if we have a way to test them :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38254 — Lester Caine — 2008-06-15T14:49:27+00:00 URL: https://externals.io/message/38234#38254 · In reply to: #38247 Pierre Joye wrote: > hi Lester, > > > > […] > > What we actually need is not C developers or new core developers > (well, we do but it is not a requirement here). We are missing tests > (as in phpt which can be run using a firebird DB) and active users > giving feedback and running these tests. Well when I originally reported the problems that were creeping into php_interbase (linux and windows) I was told that *I* should fix them, and I keep being told I should get involved more. So http://lsces.co.uk/lsces/wiki/index.php?page=PHPDevelopment Had the M$ express stuff installed on my backup W2k machine it would probably not have been a problem, but I can't upgrade it since I need W2k on that machine to test against ;) I've been through the mill with M$ installs trashing the rest of my development environment in the past, so I am not going to risk it again. > If you can write tests (you and the PHP firebird community) and run > them using our sources and binary releases, that will already do the > job. That's all we need to keep the extension alive. Testing is not a problem ESPECIALLY while we can run multiple versions of PHP on windows without the crap loaded into other applications which trash the working version and overload it with a version which may not work. I DON'T go with code that only has windows installers and would not test them ;) http://fbexport.sourceforge.net/ibtest.php.txt is our base set of tests and this shows a problem with NUMERIC(18,7) and above so we avoid that. The problem is fixing the problems we find? > > […] > > We can take care of the builds and port the firebird clients libraries > to Windows and/or MS tools. But we can do it only if we have a way to > test them :) THAT is an area where we do need to sort things out since the supplied client library is always ditched anyway and the current Firebird one used instead. From my point of view, splitting the fbird_ code from the ibase_ code and building php_firebird against a firebird client would make sense, but as has already been said - is not actually necessary - yet. http://wiki.php.net/internals/windows/libs The pages for ibase and fbclient need creating, and the project link for interbase should be ibase but I could not work out what information should be on them. In the past I have also been told that *I* need to make pdo_firebird actually work which is yet another hassle that needs sorting even if the current Firebird users do not use it :( ( To be honest *I* would rather remove pdo_firebird than php_interbase .... at least until pdo_firebird could be re-writen to replace php_interbase completely rather than our having to load both to get the functions currently lacking in pdo - but that is a separate discussion ) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38255 — Pierre Joye — 2008-06-15T15:11:37+00:00 URL: https://externals.io/message/38234#38255 · In reply to: #38254 hi, > Well when I originally reported the problems that were creeping into > php_interbase (linux and windows) I was told that *I* should fix them, and I > keep being told I should get involved more. Not easy to fix issues yourself but you are getting amazingly more involved, this step is more than welcome! > So > http://lsces.co.uk/lsces/wiki/index.php?page=PHPDevelopment > Had the M$ express stuff installed on my backup W2k machine it would > probably not have been a problem, but I can't upgrade it since I need W2k on > that machine to test against ;) > I've been through the mill with M$ installs trashing the rest of my > development environment in the past, so I am not going to risk it again. In the meantime I tried to build the 2.1.x releases (1.x dsw/dsp do not even want to be opened by vc6). It seems to work well but I met a couple of issues due to the wrong architecture detection (it uses the processor I use instead of actually using the current configartion, you can compile for x86 on x64 or cross compile for x64 on x86). Patches on their way, I suppose I can send them to firebird-developer? By the way, do you know if the 2.1 lib is 100% BC compatible with the 1.x serie? If yes, I can then use them for the php windows binaries. > > […] > > Testing is not a problem ESPECIALLY while we can run multiple versions of > PHP on windows without the crap loaded into other applications which trash > the working version and overload it with a version which may not work. I > DON'T go with code that only has windows installers and would not test them > ;) It is rather simple to run multiple PHP version on windows. You only have to uncompress the zip and run the tests. The fbclient will be statically linked (bundled in the ext). You can call the run-tests.php using the tests and script available in the src releases. I remember a howto somewhere about running tests on windows without using nmake, I will try to find it back. > http://fbexport.sourceforge.net/ibtest.php.txt is our base set of tests and > this shows a problem with NUMERIC(18,7) and above so we avoid that. > > The problem is fixing the problems we find? Can you elaborate please? Or is there a bug # in bugs.php.net? > > […] > > THAT is an area where we do need to sort things out since the supplied > client library is always ditched anyway and the current Firebird one used > instead. From my point of view, splitting the fbird_ code from the ibase_ > code and building php_firebird against a firebird client would make sense, > but as has already been said - is not actually necessary - yet. Good point, especially as interbase is actually dead. That will simply reflect the fact and we may add new 2.1 (or later) features. Feel free to create the fbclient page in the wiki and to document what could be done for 6.x (can't be renamed for 5.3). > http://wiki.php.net/internals/windows/libs > The pages for ibase and fbclient need creating, and the project link for > interbase should be ibase but I could not work out what information should > be on them. In the past I have also been told that *I* need to make > pdo_firebird actually work which is yet another hassle that needs sorting > even if the current Firebird users do not use it :( I can provide the libs in the next days as well as use them in our binaries snapshops (5.3, 6.x, maybe 5.2 if it works well and is 100% BC). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38257 — Lester Caine — 2008-06-15T16:22:39+00:00 URL: https://externals.io/message/38234#38257 · In reply to: #38255 Pierre Joye wrote: > hi, > > > > > […] > > Not easy to fix issues yourself but you are getting amazingly more > involved, this step is more than welcome! I've always been monitoring and testing - but my main activity is USING in a number of other projects ;) I should have been fixing bitweaver on windows today :( > > […] > > In the meantime I tried to build the 2.1.x releases (1.x dsw/dsp do > not even want to be opened by vc6). It seems to work well but I met a > couple of issues due to the wrong architecture detection (it uses the > processor I use instead of actually using the current configartion, > you can compile for x86 on x64 or cross compile for x64 on x86). > Patches on their way, I suppose I can send them to firebird-developer? http://tracker.firebirdsql.org/ > By the way, do you know if the 2.1 lib is 100% BC compatible with the > 1.x serie? If yes, I can then use them for the php windows binaries. The 2.1 client should access data from any older version of the server. Certainly I have no problems with FB1 running on W98SE ( Yes we still have to support that :( ) or 1.5 on Linux or Windows and I was still running IB5.6 until recently without a problem. > > […] > > It is rather simple to run multiple PHP version on windows. You only > have to uncompress the zip and run the tests. The fbclient will be > statically linked (bundled in the ext). You can call the run-tests.php > using the tests and script available in the src releases. I remember a > howto somewhere about running tests on windows without using nmake, I > will try to find it back. There was talk about dropping the .zip because the 'installer' was available. Hopefully that idea has died on the vine. > > […] > > Can you elaborate please? Or is there a bug # in bugs.php.net? Fixed - http://bugs.php.net/bug.php?id=39700 but I try and avoid snapshots so I can't test yet. 42266 is the remaining niggle that is assigned to abies and the only one of the other bugs open needs checking to see what that problem is (43674) > > […] > > Good point, especially as interbase is actually dead. That will simply Interbase is not dead! As soon as the Inprise/Borland accountants realised what they had done in trying to end of life it they tried to closed the door again. http://www.codegear.com/products/interbase - rather costly especially when Firebird is available free. > reflect the fact and we may add new 2.1 (or later) features. Feel free > to create the fbclient page in the wiki and to document what could be > done for 6.x (can't be renamed for 5.3). Not sure that there is anything new to be done. Main thing I think is transparent unicode. Firebird has always supported different collations/codesets per field in a table so has not had the restriction of other databases - which only supported a single codeset per database. Making everything UTF8 just simplifies everything in one hit and wipes out the need to manage code tables on a field by field basis :( I think that is one of the things that PDO would not allow, but it's been a while since I looked. > > […] > > I can provide the libs in the next days as well as use them in our > binaries snapshops (5.3, 6.x, maybe 5.2 if it works well and is 100% > BC). Static linking the client library may be a problem! Flamerobin needs to use the client for database management, and my legacy applications run in parallel on some machines. I run multiple web servers each with their own local legacy hardware but sharing data on a remote server. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38261 — Pierre Joye — 2008-06-15T19:17:45+00:00 URL: https://externals.io/message/38234#38261 · In reply to: #38257 hi Lester, > > […] > > I've always been monitoring and testing - but my main activity is USING in a > number of other projects ;) That means you know it and how it works with php, that's what we need now :) > > […] > > http://tracker.firebirdsql.org/ Ah right, the tracker. Thanks for the link > > […] > > The 2.1 client should access data from any older version of the server. > Certainly I have no problems with FB1 running on W98SE ( Yes we still have > to support that :( ) or 1.5 on Linux or Windows and I was still running > IB5.6 until recently without a problem. I will use with 2.1 for 5.3+ and keep using what we have now for 5.2.x. That will be a good test for the new lib. > There was talk about dropping the .zip because the 'installer' was > available. Hopefully that idea has died on the vine. There is no plan to drop the zip releases. > > […] > > Fixed - http://bugs.php.net/bug.php?id=39700 > but I try and avoid snapshots so I can't test yet. > 42266 is the remaining niggle that is assigned to abies and the only one of > the other bugs open needs checking to see what that problem is (43674) Any chance to turn the ibtest.php.txt scripts into a set of phpt files? It can then be used as main tests for php (make test or with run-tests.php). I can give try to fix it and use the tests to valid my changes. > Interbase is not dead! As soon as the Inprise/Borland accountants realised > what they had done in trying to end of life it they tried to closed the door > again. http://www.codegear.com/products/interbase - rather costly especially > when Firebird is available free. Oh, I thought it was not maintained anymore. > Not sure that there is anything new to be done. > Main thing I think is transparent unicode. Firebird has always supported > different collations/codesets per field in a table so has not had the > restriction of other databases - which only supported a single codeset per > database. Making everything UTF8 just simplifies everything in one hit and > wipes out the need to manage code tables on a field by field basis :( I > think that is one of the things that PDO would not allow, but it's been a > while since I looked. That could be possible without unicode if mbstring is available (for the end users to decode the return value). Unicode support and conversion abilities obviously help a lot more. Can you describe the needs in the wiki please? And maybe what would be nice to add? That will be useful for anyone willing to contribute and looking for some todos. > > […] > > Static linking the client library may be a problem! Flamerobin needs to use > the client for database management, and my legacy applications run in > parallel on some machines. I run multiple web servers each with their own > local legacy hardware but sharing data on a remote server. Ah right, we do it dynamically already (was looking for fbclient but we still use gd32.dll :). -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38263 — Lester Caine — 2008-06-15T22:00:00+00:00 URL: https://externals.io/message/38234#38263 · In reply to: #38261 Pierre Joye wrote: > > […] > > Ah right, we do it dynamically already (was looking for fbclient but > we still use gd32.dll :). Still need gds32.dll for compatibility with Interbase. That is why a php_firebird may now be appropriate. I'm doubt that Interbase will work with the fbclient - in fact I suspect that even Interbase users would need a newer gds32.dll from the Interbase install to access the current versions of Interbase! Just don't know of anybody rich enough to use Interbase ;) 5.3.0 snapshot runs clean on the ibtest package but we do need to extend that to add a few more blob tests. bitweaver runs except for a number of 'Deprecated' errors, so the blob functions are still fine. Just need to work through the list of 'Deprecated' errors and see if we can do anything about them AND maintain BC .... 1/ Assigning the return value of new by reference is deprecated 2/ The is_dst parameter is deprecated in mk/gmmtime Only thing I spotted was a silly with php.ini. I had - path\" - as the end of the include path, and PHP5.3.0 then used the whole of the rest of the ini file as the include path! Drop the '\' leaving path" and everything is fine. I think the '\' was there originally because of a problem with it not being added, but it does seem that it is no longer needed? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php