Quick review of old bugs fixed for Delphi
David I. had an interesting question for the team - are we fixing enough of our older bugs in the product? Are we neglecting past issues reported by our customers?
As a resident quality champion, of course I want to know too 
So I took a quick query into the bug tracking system, and looked at how many reports found earlier then Jan 1, 2009 were fixed this year. A quick, no fuss query though I made sure to only include bug reports (not feature requests) and resolutions related to bug fixing.
The result?
711 Delphi bugs found earlier then Jan 1, 2009 have been fixed so far this year, and the team is in middle of polish phase for the next release "Weaver".
The next question is how many came from customer reports? So I looked at the number coming from Quality Central - 222 of those 711 are Quality Central reports. Not an insignificant number. A number (about half) of those were released in RAD Studio 2009 Updates 3 and 4 with the remainder going into Weaver. As I mentioned - more is being done as well.
Additional slices:
- 198 of the 711 were reported earlier then 2008
- 116 reported prior to 2007
- 91 reported prior to 2006
That’s good news, and a sign the team looks at older issues as well as new.
With 10 years of reports, there is a mixed bag of about 2000 public reports the team is constantly working on, and our beta feedback helps guide the release to ensure it’s a good one.
As always, we can improve- and need to to stay ahead of the pack. So let me know if you have a QC report you feel is neglected. I’ll take a look at it.
July 1st, 2009 at 12:15 pm
I dont know…how about bug fixes for rad studio 2007!!!! Those numbers mean nothing to me unless I can update something other than 2009.
I have been using delphi since version 1. Now I am pissed off as there has been no updates to rad studio 2007. Pull you finger out and support your customers.
July 1st, 2009 at 1:00 pm
Hi Graeme,
RAD Studio 2007 was released in several phases with each phase having additional bug fixes. Delphi 2007 was the first release, with 3 updates to it by the time RAD Studio 2007 released (which included Delphi 2007 and C++Builder 2008) and then we released an additional December Update:
http://edn.embarcadero.com/article/37442
In purchasing the release, there is an option to buy maintenance which is for a year, and ensures you get all latest new product releases during that period. I think it’s a pretty good deal, and a good way to help the development team stay focused on next releases features and quality, and supporting existing customers.
Maintenance is about 50% of the upgrade price, so with annual releases is a pretty good deal for the customers.
I understand with RS 2007 some folks are hesitant to move to RAD Studio 2009 due to the Unicode changes, there is a lot more then that though and Andreano covers it really well in this paper:
http://cc.embarcadero.com/Item/26707
This probably sounds like it’s blowing you off, the team has a choice of how much effort to spend on past releases and with 4 updates total to D2007 that was considered ‘pretty good’ for our customers.
There is a certain point in the code base where the cost to fix previous releases is too great, and then the new features that customers ask for suffer.
If you have specific bugs that are blocking you in RAD Studio 2007, can you call them out? Be happy to look at them for you.
Thanks for your comment, hopefully you can see that yes the team does do several updates, then has to move on to the next release.
Regards,
Chris
July 1st, 2009 at 8:29 pm
Hi Got Delphi 1 when it first came out, as a personal license. I then got a job, where I worked with Delphi 2, 3, 5 and 6.
I then started my own business, and bought Delphi 7, skipped 8, but bought 2006 with maintenance (I think), so I have now worked with 2006, 2007 and I am currently working on 2009. Very few of my projects have to be lifted to newer Delphi. As in the software I make, Delphi too has some bugs, I have however yet to find a bug that really is a showstopper. Some of the bugs are really annoying, but I can usually get the work done anyway.
I have built some programs that customers are running, but I stringly suggest the customers to upgrade so they allways have latest version. Spares me the trouble of maintaining old software, gives me the time to implement new and cool features of the current version. If the customer has a bug, I’ll fix it, but if he is using a two or even three version older version, I only fix the bug if there is no workaround, and its a showstopper, or its really really simple.
I have found quite a lot of bugs in the past 14 years is it of Delphi? But I havent run into any showstoppers. I’m not saying that other people havent. I think that Codegear is doing the right thing, concentrating more on current and future versions, than on older versions..
This opinion is obviously only until I discover some bug in my Delphi 7, that I cannot workaround…
Just my two bits.. Codegear, thanks for a real good product.
Jens Fudge
July 1st, 2009 at 8:30 pm
Chris,
Please take a look at this topic:
https://forums.codegear.com/thread.jspa?threadID=19261
Bas
July 1st, 2009 at 8:54 pm
>> 711 Delphi bugs found earlier then Jan 1, 2009 have been fixed so far this year
I don’t think so, most of them you marked with "Won’t do","Feature Removed" or "Test Case Error".
Here is my personal list. I have reported 33 issues since 2002.
Report No. Year Resolution
#2775 2002 Won’t do
#2970 2002 Fixed
#4539 2003 Withdrawn
#6446 2003 Retest
#6471 2003 As designed
#6580 2003 Dublicate
#6657 2003 Retest
#6934 2004 Fixed
#7158 2004 Withdrawn
#8286 2004 Feature Rem.
#8445 2004 Retest
#8481 2004 Fixed
#8763 2004 Feature Rem.
#9506 2004 Feature Rem.
#11763 2005 Retest
#13462 2005 Feature Rem.
#19716 2005 Open
#21949 2005 Won’t do
#27048 2006 Feature Rem.
#36963 2006 Open
#39959 2007 Open
#40082 2007 Open
#47939 2007 Open
#47940 2007 Open
#48800 2007 Open
#49777 2007 Open
#50507 2007 Open
#51361 2007 Open
#53160 2007 Withdrawn
#58409 2008 !!!!!
#62398 2008 Cannot Rep.
#63153 2008 Fixed
#63520 2008 Fixed
5 Fixed out of 33 during the past 7 years.
July 1st, 2009 at 10:27 pm
The most voted ever bug for a 64-bit compiler support has been closed, but as far as I know there is no 64 bit compiler yet.
A feature I have been waiting for for ages as I need to be able to support more than 2GB of memory.
Can you please reopen it?
http://qc.embarcadero.com/wc/qcmain.aspx?d=7324
July 1st, 2009 at 10:45 pm
Hi Chris I have report about 49 issues
Closed
#67923 because too many report in one
#69800 Cannot Reproduce (but the bug style existe in Windows French versions)
#69760 Closed in my request
Fixed
#69763
Withdraw
#71736
Opened
#69759 (feature request)
#70406 (feature request)
#69761 and #69762 (duplicate because try to attach unsuccessfuly
#70431
#70829
#71875
#71878
Reported neighter opened nor closed 36
27 of them concerning BiDiMode
Some of them have a work Around and most of them were published before SP3.
This does not encouraged me to publish other bug, because as you see, I don’t speak english very well, so I have to do effort to try to explain.
When I see that SP3 & 4 are published in May and sources of bug fixed have the date of Jan 14 2009, I can’t understand why the team stop fixing the bug in this date.
Very sorry of my bad english
July 2nd, 2009 at 12:15 am
I disagree strongly that maintenance is a good idea! I Upgraded to Delphi 2007 on release. I purchased maintenance at the time. I got ABSOLUTELY NOTHING for it. There was nothing released in the next 12 months that required a maintenance contract. I never even recieved ANY KIND of communication until I got one asking to pay for renewal, which, unsurprisingly, I declined, letting them know how cheated i felt. I would never take out maintenance as it stands.
To be attractive, the maintenance should be for one year OR at least one major release.
July 2nd, 2009 at 1:30 am
Hi
Well, it does seem like a lot of people are annoyed with bugs.. Maybe I’m using my Delphi in a different manner, I really dont experience many bugs.
I am not saying they are not there, but it seems that the kind of stuff I do, dont get into those areas..
It is however interesting, that sometimes people confuse the terms "new features" with "bugs".
As far as I know, Codegear never stated that Delphi came with a 64bit compiler. I totally agree, I would really like a 64bit compiler too, but it cannot be a bug.
A bug is when the BinarySearch function gives you the wrong result or something. I dont even think its a bug that Delphi cannot compile to Linux, mac osx, unix or any other OS thinkable, even though I would really like it..
I did read the link about the gif unit not being fixed, and the original auther said he could do it.. And yes, i do agree.. Codegear should sort it. As should they sort the other bugs that are there.
And yes, maintenance should include one major release..
Best regards
Jens Fudge
July 2nd, 2009 at 1:54 am
Implement Andy’s fixes:
http://andy.jgknet.de/blog/?page_id=246
http://andy.jgknet.de/blog/?page_id=288
Some smaller IDE annoyances:
55633 When active item has edit button, it’s not visible at first
43703 Possibility to hide toolbar in breakpoint window
24999 Hint area is wrong, giving recreate problem on boundary
19655 Wrong highlighting of the message word
13469 Make use of $REGION on wizards for forms/datamodules/webmodules etc.
11324 Refactoring does not handle the comment made by class completion
10478 Highlight string start and end tag feature behaviour
6589 Dissappearing debug marking (still a problem….)
Major IDE annoyance:
43099 Cursor hint response when working with keyboard in editor
Showstopper for use of Block Completion (makes it easier without it):
23472 Block completion work wrong with unfinished code under workarea (wont do.. why and who said that?)
Very important, especially if you want cross compile/debug later:
23807 Current Remote Debugging generates a lot of actions before every use
VCL:
24128 FileCtrl.pas SelectDirectory has wrong control focus
15057 TStrings does not follow design path for TPersistent
Major VCL annoyance:
10567 Ability to create all VCL packages
(You really should make it easier for us to implement fixes in VCL and be able to post back changes for review)
If you want people to use TSOAPDatamodule:
12979 DSML SOAP Session Support in TSOAPDatamodule
With new RTTI features (big wish from me):
26833 Visibility for design objects components should not be public
I guess this one could be closed:
26801 RTTI functionality for private and protected sections in classes
July 2nd, 2009 at 4:51 am
This is great feedback, I’ll pass on to the core management team to ensure it’s reviewed. Several of the issues such as old libraries not being updated are getting looked at.
Jan, the QC report on 64 bit compiler is Deferred until a future release, it’s not closed for good. I need to look at how feature requests are handled in QC by the team to avoid such confusion.
Atle, I looked up on the showstopper you mentioned and see this issue ‘Cannot be Fixed’ with following comments:
[QC] From Andreas Hausladen:
This bug can’t be fixed. If the code is changed to satisfy the bug report it will break the "if-begin".
The bug report requests:
procedure t;
begin
| No "end;" should be inserted because there is a second "begin" below the cursor
procedure t;
begin
begin
| "end;" should be inserted because the second "begin" is above the cursor
But this breaks the following construct:
procedure t;
begin
if True then
begin
| "end;" should be inserted but there is a second "begin" below the cursor !conflict!
Adding the "above and below begin" logic only to the most outer "begin"
doesn’t work either. I tried it. It disables the whole BlockCompletion.
Without a brain reader this bug report (the second part of it) can’t be fixed.
I’ll summarize the list of other issues mentioned by folks, and get them to the team for review.
Thanks,
Chris
July 2nd, 2009 at 4:54 am
Paul, feel free to shoot me an email with your maintenance dates and agreement. There were several releases last year, I’d have expected you to be covered for at least one major release with maintenance. Very odd if not and I’d like to see what happened.
chris.pattinson@embarcadero.com
Thanks,
Chris
July 2nd, 2009 at 5:50 am
Yes we can use RAD studio 2007 every day having the work done. The problem is that all IDE bugs really slow down the development of a sofwate solution.
For example, when nagivating through code and the IDE doesn’t point you at the right place (ctrl+click for exemple). This is a major issue. This is a should repair bug.
I know, RAD Studio 2007 is really old stuff, but hey, after buying a ten pack of enterprise license (about 25k) and 6 months of use, no chance to get a service pack? I don’t think this could be called customer’s respect.
Delphi is great.
Support is poor.
July 2nd, 2009 at 6:24 am
Here’s one I reported a long time ago which has never moved past "reported" state:
http://qc.embarcadero.com/wc/qcmain.aspx?d=58704
You might run a query of old issues in "reported" state to get a feel for how many reports are falling through the cracks…
July 2nd, 2009 at 11:57 am
We are using C++ builder 2007 on a current project.
The linker is the biggest pile of crap.
Just try and use in in large applicaitions and it just dies, dies, dies….and my god is it slow……
July 2nd, 2009 at 12:08 pm
http://andy.jgknet.de/
does more good fixes than what we recieve from support.
I have developers (from microsoft background)laughing…yes laughing at all the bugs they a forced to work against.
I love delphi, c++ builder. But never again will i recommend for a project. never.
July 2nd, 2009 at 12:13 pm
@Graeme:
It’s C++. What do you expect? It compiles and links very slowly and everyone knows that. (Especially if you use non-trivial templates.)
July 2nd, 2009 at 3:57 pm
Here is a Error insight QC that has been closed but I’ve still got the issue in Delphi 2009 with Update 3&4.
http://qc.embarcadero.com/wc/qcmain.aspx?d=58662
I didn’t understand the resolution comments.
There are numerous other QC relating to this issue eg #33546, #22880 so I guess that’s another reason to close issues (but it doesn’t mean they have been resolved!)
July 2nd, 2009 at 9:00 pm
I would like to get #26318 fixed. Now I have to modify ComCtrls.pas and copy it to my project.
Best resolution is to add another event passing the year.
This really can’t be that much work?
July 2nd, 2009 at 10:05 pm
About the Block Completion, it is possible to create a better behaviour. The general idea is that whenever you are not sure where the "end" should be put, don’t do it automatically.
I guess this was your scenario?:
proc something;
begin
if something then
begin
begin
end
end
Let’s walk through that one. There is less begin than end total, and more begin than end before, there is more extra begin versus end before cursor than after cursor, and next tag is not end, so it should generate a "end".
Solution solved..
July 3rd, 2009 at 12:04 am
And how about .NET personality of D2007, basicaly it’s screw you poor users, IE 8 update breaks D2007 ASP.NET designer which doesn’t work so good in the first place. I am thinking that that is my fault, because I was stupid enough to trust CodeGear and doing ASP.NET work in delphi 2007.
And talking about upgrade to Prism, you may fuck me once but not twice, sorry I really love Delphi but Prism is not Delphi, and so many VS.NET features doesnt work in Prism, especially in VS.NET Team System.
July 3rd, 2009 at 2:27 am
Btw. All TDictionary bugs still open should be fixed, they are all nasty.
July 3rd, 2009 at 5:30 pm
If you really want to convince customers you are taking their concerns about quality seriously, I suggest the following approach:
When you release a new version of the product, create a webpage that essentially contains the features matrix but with another column marked quality. Let each row in the column carry an Amazon like scoring system. e.g. score out of five displayed, and clicking on the score brings up a reviews page dedicated to that feature. This would firstly focus the development team on improving the areas that were getting the most attention from users and secondly enable potential buyers to tell at a glance if a feature they cared about had actually been fully implemented and tested.
A matrix with lots of low scores would be an embarrassment and certainly something to focus minds. At the same time though, positive reviews for a feature would help to sell more products. How many people are sticking with Delphi 7, because they simply don’t have confidence in later releases to do they what they need? After all overall product quality improvements don’t mean much if the functionality you need doesn’t work.
And finally make sure that comments are restricted to ordinary customers, not TeamB evangelists.
Maybe you could implement the system in Delphi for PHP.
July 4th, 2009 at 2:47 am
What about Webdeploy menu for activex?
I cannot do a new activex in Delphi2007 but I have to prepare it in Delphi 7 and then I recompile it in 2007.
Chee Wee expert cannot solve every problem.
Is this so difficult to solve?
Delphi 2009 lost web deploy too? I posted a question on EDN a mounth ago and it isn’t answered yet.
Am I the only delphi user who is writing activex?
Yes, I know that I can write a web page from myself (and it was my solution) but it seems we are alone.
July 4th, 2009 at 11:55 pm
Nasty bug:
Report No: 59963 (RAID: 258597) Status: Open
PopupMode=pmExplicit doesn’t handle correctly the closing of forms in certain cases
http://qc.codegear.com/wc/qcmain.aspx?d=59963
Major annoyance:
Report No: 45282 Status: Reported
Wrong handling of floating all IDE editors
http://qc.codegear.com/wc/qcmain.aspx?d=45282
Kudos for your effort in trying to enhance the product further. But because there are some phenomena popping in the community can you answer to the following questions? (Please give your _personal_ POV, isn’t a PhD exam here
)
What means ‘Quality’?
What means ‘Crowdsourcing’?
What means ‘Streamlined workflow’?
July 6th, 2009 at 12:24 am
My reports are still open:
#71595 : Form resizing issue
#72024 : VCL controls flashes on resize
#72175 : Range check error in TGifImage
#72396 : Request Event: OnCheckedChange for TRadioButton and TCheckBox
all of the are before 2009/3
July 6th, 2009 at 2:16 am
@Jan Derks: The 64-bit compiler request has not been closed, but it has been deferred to "next version". Apparently that won’t be "Weaver" though. At Delphi Live! they stated that 64-bit will still need a while because the compiler needs quite a bit overhauled for that …
July 6th, 2009 at 1:48 pm
Hi JB,
We’re working through the reported issues constantly.
The interesting thing about QC is it was originally intended as a public self-support system, where Sysops would promote into the main bug area. If a report was not deemed worthy enough to promote, it was left in the ‘bucket’. A couple years ago, I had QA take over looking at the reports, and the team could do fairly well on incoming reports.
The ‘debt’ of the old public reports is something the team is very aware of, and basically tries to triage based on public voting, reproducibility and severity of the issue.
I’d love to see more public voting on issues, so we can prioritize better - otherwise the team is just working away as methodically as they can, and we take critical input from Beta Test Marshals on their ‘Top 10 Customer Issues’ lists - working on those as a top priority.
Regards,
Chris
July 6th, 2009 at 1:53 pm
Hi David,
I really like that idea. I’m all for public surveys and ideally a grid of the feature areas that lists the public perception of quality. I’ll discuss with Michael Rozlog when he’s back from vacation.
I really DO want to hear your top quality issues and top bugs. QC was made to make such feedback by the public possible, and let the community itself vote on issues and help prioritize bug fixing work. The public bug reports are visible, queryable and votable. We also have statistics that show which areas get the most bugs and feature requests.
It’s a good way of doing it IMO, since a basic ‘5 star’ does not give you concrete information on what exactly you need to improve - just that there is a problem. QC gives us hundreds of areas we can improve, then it comes down to voting and prioritization of which improvements to do first.
Thanks,
Chris
July 6th, 2009 at 1:56 pm
When Michael Rozlog produces the next Delphi/RAD Studio he’s the ultimate authority on feature priority and rough schedule.
Graeme - As to C++Builder - we took several hundred new fixes including some really critical ones to the Linker in C++Builder 2009. More has been done since with Weaver, I suggest trying out the 2009 Trial and see if the linker bugs you mentioned were fixed as a part of those changes.
C++Builder is still supported by a significant compiler and QA group. David Dean usually does a great job tracking down such issues, so feel free to contact me with QC numbers and/or information which I’ll forward on to David and the team to look at.
Thanks,
Chris
July 7th, 2009 at 9:36 pm
Chris
i suggest you to change a bit the bug-fixing mode that you work in.
i see the key problem in fact that you select only bugs you find important and try to fix them. well, this is not bad itself, but often it results the situation when for certain area there are couple of important fixes, but the area still cannot be used because of other bugs.
in this case your statistics about number of fixed bugs looks quite useless. I mean the aspect of "i don’t care about amount of fixes, i need this thing working!".
great example for that is TListView component. you add support for new features like groups and so on. however, there are tons of bugs in VCL sources related to this control and they are not fixed. So it’s hard actually to decide to use the control because of new features - knowing that all bugs are still there.
(i mentioned TListView because it is quite complicated control - a lot of subclassing used and so on. we cannot easily change sources to fix painting problems or problems with dragging columns - it is easier to buy commercial component or download VirtualTree for free).
so, what i propose to you is to make small, eh, support updates that are focused on single areas.
in other words, you take all bugs for, say, list view control and fix them. ALL, important and not important. i’m not talking about adding new features. no, just fixing bugs.
i makes much more sense to have 4 of 10 areas working perfect instead of 10 of 10 being fixed, but having 0 of them usable.
PS. so it would be good initiative: say, "update XX contains fixes for all components from Standard page", then "update XX contains fixes for all components from Additional page" and so on. The same thing can be made for IDE-related stuff and so on. if you do this way, the overall logic of development/support will be much more clear for the public.
July 8th, 2009 at 1:50 pm
Michael, that’s not a bad approach. Especially as it could isolate testing and also help focus the team.
This is effectively what was done for Update 1 for D2009- that was mainly a RibbonControls VCL update patch. Update 4 was focused on database fixes. The Update 3 was a more comprehensive update where riskier and deeper changes were managed - I think it’s a good approach to have some small focused updates, then a general comprehensive one.
We can look at doing more focused, smaller ones in the future. The team does try and prioritize based on all feedback coming in from all sources.
Regards,
Chris
July 9th, 2009 at 1:58 am
Chris
Well, what can I say? Nice to hear
July 9th, 2009 at 6:57 am
Hi Chris
Why don’t your team release hotfixes between updates.
For example the issues for compiler about generics was serious but we had to wait for update 3 to arrive.
That would be nice to have hotfixes for important issues before any major update.
Regards,
Salar
July 14th, 2009 at 11:05 am
Hi Salar,
We often release hotfixes, there were over a dozen in D2007 time frame that then rolled up into a hotfix pack. D2009 we had several small updates and then the larger one.
Both team and management provide input into what should go into a hotfix or update, and the scope of it. We are especially sensitive to maintaining backwards compatibility and functionality. I certainly don’t mind if anyone notices something broken that used to work and send me an email - QA ’should’ catch all such cases with the large set of regression tests that are run daily.
Regards,
Chris
August 1st, 2009 at 5:13 am
Great timing on this posting…
I wasted about 2 hours of my Thursday morning on a bug that has been out there for what appears to be nine years now.
The imfamous 4GB free-space bug in the BDE. We have one app that still uses the BDE and it is not our app, so we cannot migrate to another database technology.
If you are not familiar with the bug (I was not either until Thursday), it causes intermittent ‘out of disk space’ errors in your app if the free space happens to be near an exact multiple of 4 GB. In my case, I was getting out of space errors on a machine with 56 GB free.
There was a half-hearted attempt to patch in 2004, but from the reports I read it came with it’s own batch of problems.
For those of us who inherited a BDE product, how about a quick fix for this? It could not be more than a couple of lines of code - if you still have the source laying around somewhere
Thanks,
David
PS - My workaround for this? I copied a half-gig of junk onto the drive to get to 55.5 GB free and everything started working again.
August 1st, 2009 at 6:33 am
I also stopped to add any found bugs to the quality central. The bugs are never fixed or declined without any cause, etc. The support is very bad.
Best example on closing without any further reaction is QC # 62498. Even the given resolution comment shows that this is a internal design failure - and was even correctly handled in earlier versions.
Another example on how worse the support is, is case # 3239. Reported in 2001 (year is not correct in QC) (found in Delphi 5) and fixed in 2006 in Delphi 2006. Wow - fast fix - it’s amazing, because the fixed structure was posted on creating the entry. Just copy & paste takes some years…
And their is still the big lack on all things affecting the usage of delphi sources in C++Builder. All the new features of the delphi language are simply never tested in C++Builder. The Header generator is a complete show stopper here. We use such combined projects and have to fix the headers on every build process. Even delphi compiler options are not offered in the IDE (DebugInLib) or just simply not passed to the pascal compiler (enum size). It is simply sometimes unusable…
Here are some other bugs that are still open and show stopper when using Delphi with C++Builder…
69296, 53994, 52682, 42782
But the goldiest thing I ever is bug 42782. The HPP generation is basicly wrong on const pointer declarations since generation hpp. Never used by codegear so nobody got’s crazy on the needed const_cast. The HPP generator has to be build with people from Delphi & C++Builder and they have to get in common. The new feature of the Delphi language is partly incompatible with C++ (e.g. the class inside a class declaration) and so the very good feature of using Delphi sources in C++Builder projects gets lost. Destroyed by codegear itself - and the user has to fix and test it.
Regards,
Thomas
August 3rd, 2009 at 9:24 pm
We have been waiting for a solution to our two reports for three years now
We have 5 licenses of BDS2006 Enterprise.
In this time we have had to live with that bugs doing the following…
BUG 33679
The mark’s discussion help us to find a way to change the threading model of a Classic web service… , but to use a delphi dll into a WCF service was different and we didnt have way to change de threading model because WCF don´t use the classic httphandler of ASP.NET 2.0.
In this case we had to change Borland.Vcl.DSIntf in that form:
procedure CreateDbClientObject(const CLSID, IID: TGUID; out Obj);
var
Factory: IClassFactory;
begin
// APM comentado para ver si funciona en MTA
//CheckThreadingModel(System.Threading.ApartmentState.STA);
CheckDbClient(CLSID);
Factory := DllGetClassObject(CLSID, Guid.Create(CLSID_IClassFactory));
Factory.CreateInstance(nil, IID, Obj);
end;
For now is running well because is a web service with little concurrency.
I think that is time to prepare midas.dll for the future because if not you are limiting de future of dbexpress on internet applications because everybody
do the bussiness logics with TClientDataset->TDatasetProvider->TSqlQuery to compile one version code to win32 and dotnet.
BUG 35900
use of database aliases in sql sentences in INFORMIX is not supported
The last year we ported a Delphi 7 application to Delphi 2006 and with the patch:
Unit SQLExpr.
procedure TSQLQuery.QueryChanged(Sender: TObject);
begin
if not (csReading in ComponentState) then
begin
Close;
SetPrepared(False);
if ParamCheck or (csDesigning in ComponentState) then
begin
FCommandText := SQL.Text;
FText := FCommandText;
SetParamsFromSQL(nil, False);
{ TODO : CAMBIO REALIZADO POR APM PARA QUE FUNCIONEN LAS QUERYS DE SQLSERVICES } FText:=FNativeCommand;
end
else
FText := SQL.Text;
DataEvent(dePropertyChange, 0);
end
else
FText := FParams.ParseSQL(SQL.Text, False);
SetFCommandText(FText);
end;
Unit DB.pas
function TParams.ParseSQL(SQL: WideString; DoCreate: Boolean): WideString;
const
Literals = ['''', '"', '`'];
var
Value, CurPos, StartPos: PWideChar;
CurChar: WideChar;
Literal: Boolean;
EmbeddedLiteral: Boolean;
Name: WideString;
posicion:Integer;
function NameDelimiter: Boolean;
begin
Result := inOpSet(CurChar, [' ', ',', ';', ')', #13, #10]);
end;
function IsLiteral: Boolean;
begin
Result := CurChar in Literals;
end;
function StripLiterals(Buffer: PWideChar): WideString;
var
Len: integer;
TempBuf: PWideChar;
procedure StripChar;
begin
if TempBuf^ in Literals then
begin
WStrMove(TempBuf, TempBuf + 1, Len - 1);
if (TempBuf + (Len -2))^ in Literals then
(TempBuf + Len-2)^ := #0;
end;
end;
begin
Len := WStrLen(Buffer);
TempBuf := AllocMem((Len + 1) * 2);
try
WStrCopy(TempBuf, Buffer);
StripChar;
Result := TempBuf;
finally
FreeMem(TempBuf, (Len + 1) * 2);
end;
end;
begin
Result := SQL;
Value := PWideChar(Result);
if DoCreate then Clear;
CurPos := Value;
Literal := False;
EmbeddedLiteral := False;
repeat
CurChar := CurPos^;
if (CurChar = ‘:’) and not Literal and ((CurPos + 1)^ ‘:’) then
begin
StartPos := CurPos;
while (CurChar #0) and (Literal or not NameDelimiter) do
begin
Inc(CurPos);
CurChar := CurPos^;
if IsLiteral then
begin
Literal := Literal xor True;
if CurPos = StartPos + 1 then EmbeddedLiteral := True;
end;
end;
CurPos^ := #0;
if EmbeddedLiteral then
begin
Name := StripLiterals(StartPos + 1);
EmbeddedLiteral := False;
end
else Name := WideString(StartPos + 1);
if DoCreate then
TParam(Add).Name := Name;
CurPos^ := CurChar;
StartPos^ := ‘?’;
Inc(StartPos);
WStrMove(StartPos, CurPos, WStrLen(CurPos) + 1);
CurPos := StartPos;
end
else if (CurChar = ‘:’) and not Literal and ((CurPos + 1)^ = ‘:’) then
begin
WStrMove(CurPos, CurPos + 1, WStrLen(CurPos)) //APM//
// posicion:=(Curpos-value);
// Result:=Copy(Result,1,posicion)+Copy(Result,posicion+2,length(Result)-(posicion+1));
// curpos:=PWideChar(Result);
// curpos:=curpos+posicion;
end
else if IsLiteral then Literal := Literal xor True;
Inc(CurPos);
// Value:=PWideChar(Result);
// posicion:=(Curpos-Value);
until CurChar = #0;
// until (posicion)>=Length(Result);
end;
Please we are customers of codegear from delphi 3 , I think that is time to do anything.
Thanks for all….