http://edn.embarcadero.com/article/32400 2009-07-09T13:00:54-07:00 Craig Nicholson http://threads.embarcadero.com/threads/threads.exe/userall?commentid=38114 http://threads.embarcadero.com/threads/threads.exe/view?commentid=38114 2005-01-31T02:20:39-08:00 2005-01-31T02:20:39-08:00

re: Delphi 7.1 update has been fixed and is live

I totally agree! Craig Nicholson http://threads.embarcadero.com/threads/threads.exe/userall?commentid=38113 http://threads.embarcadero.com/threads/threads.exe/view?commentid=38113 2005-01-31T02:19:08-08:00 2005-01-31T02:19:08-08:00

Delphi 7.1 update has been fixed and is live

It might be an idea if the updates page dates (5/27/2004) were changed to reflect the new version. Hans-Dieter Karl http://threads.embarcadero.com/threads/threads.exe/userall?commentid=37254 http://threads.embarcadero.com/threads/threads.exe/view?commentid=37254 2004-07-06T10:07:37-07:00 2004-07-06T10:07:37-07:00

Delphi 7.1 update has been fixed and is live

looking in borland.public.delphi.upgrade and borland.public.delphi.language.basmthe 7.1 upgrade seems to introduce severalcompiler "problems" ...i'm waiting for an official statement from borland! Rolf Einar Eriksen http://threads.embarcadero.com/threads/threads.exe/userall?commentid=37222 http://threads.embarcadero.com/threads/threads.exe/view?commentid=37222 2004-07-02T04:44:12-07:00 2004-07-02T04:44:12-07:00

Delphi 7.1 update has been fixed and is live

Why have you fixed this problem, but not the MUTCH worse problem that the compiler now in many cases produce code that runs twise as slow as it did before. The optimizer is totally ruined by the 7.1 update. This should be fixed as soon as possible...Right now I have to manually copy my 7.0 dcc32.exe and dcc70.dll before I run the update, and then copy it back.If you want examples, I've posted them to DavidI a long time ago. Bob Fleischman http://threads.embarcadero.com/threads/threads.exe/userall?commentid=37153 http://threads.embarcadero.com/threads/threads.exe/view?commentid=37153 2004-06-21T13:57:52-07:00 2004-06-21T13:57:52-07:00

Delphi 7.1 update has been fixed and is live

If I have already applied the 7.1 upgrade what do I do now?? Paul Ericksen http://threads.embarcadero.com/threads/threads.exe/userall?commentid=36896 http://threads.embarcadero.com/threads/threads.exe/view?commentid=36896 2004-06-11T07:44:04-07:00 2004-06-11T07:44:04-07:00

use at your own risk.

After some experimentation, I have encountered an error that many users may not experience, but thought I should give caution to.I have a program that allows the users to select which field they want to group on. The program must construct the SQL on the fly to fit whatever their criteria is. Sometimes they are summarizing by the ItemNum, sometimes by the ItemClass, sometimes by the VendorNum. All the rest of the SUM() fields remain the same. So one query may look something like this:select it.itemclass as grouping, sum(price), sum(cost) from ardetail ard join item it on (ar.itemnum = it.itemnum)group by it.itemclassand when they change a radio button it would look like this:select it.vendornum as grouping, sum(price), sum(cost) from ardetail ard join item it on (ar.itemnum = it.itemnum)group by it.vendornumVery simple change to the query. We just build the query on the fly and reuse the query component and fields. Since we are doing field aliasing it will always look like the same field name. We have code, graphs and grids referencing this field as "grouping". The way the WHERE clause is built remains the same (including: date, class, brand, vendor, sales rep restrictions).The problem with the fix is that if you run a query where the field name that is getting swapped out returns data from a field that is 2 characters, then run another query with the same component where the field is now returning 10 characters, even though the field size is set to 10 to hold the maximum characters it can return, the TField has stored the meta data from the **previous** query and will think there's an error getting 10 characters into a 2 character field. It raises an error saying "Size Mismatch - Field x size is too small for data" when we access the .AsString for the field.In other queries of ours, users may have a column invisible. That column comes from a joined table that is only joined in when the column is visible because of the expense of the join -- the rest of the time our SQL has " '' as PRICEBOOKNAME". This query works until you try to view the extra column because the TField has kept the internal meta data that the field was last seen as 0 size.We have another screen which allows users to change what table they are searching on. They are simple CODE, DESCR lookup tables, but they are non-uniformed sized fields. We have one screen which has great selection, filtering and search ability that can work for a variety of tables thrown at it. We change the query to point at the different table but with the 7.1(.1) fix, the next query we open will need to have fields the same size or smaller, or we will get the exception.I realize we are using some simple tricks for convenience purposes, and that Borland may not test for stuff like this. I believe the TField should look at the metadata for the query when it opens now, not just from the last query that opened (which it appears to do).This may not be enough of an issue for other people who do not employ such tricks, and I would recommend the 7.1 fixed update.However, for the other people who need to do stuff like this with your queries, be careful. I don't think that Borland will resolve this so we are planning to change all of our queries that use such tricks to have "CAST(fieldname as CHAR(10)) as GROUPING" so that it will always come back as a 10 character field regardless of what we are switching it out with. It leaves me uneasy, because we may not find everything. David Heffernan http://threads.embarcadero.com/threads/threads.exe/userall?commentid=36893 http://threads.embarcadero.com/threads/threads.exe/view?commentid=36893 2004-06-10T02:43:22-07:00 2004-06-10T02:43:22-07:00

Delphi 7.1 update has been fixed and is live

How can you release 2 different patches both with the same version number (7.1)? Surely it is better QA to call the second one 7.2 or in fact anything different from 7.1?Perhaps you feel that if you release patch 7.2 so soon after 7.1 then you will be criticised for released poor code which needs lots of patching.The solution is not to release a patch for the original update and give it the same version number. I mean, why bother with version numbers at all?!There is nothing to be afraid of fixing bugs. The fact the you have done so is something to be proud of - lots of companies won't fix bugs at all!David Heffernan.