Expression index doesn't work

Description

Reported by Roy Tate

Using a DBase table, with an expression index active (for example: Indexed Field = [FIELD1] and Subset Condition = [FIELD2 = "1"]), the DbLookupCombo and DbLookupList are unpopulated. In our example, there were 20 or more records meeting the condition, but the list/combo show nothing.

Further investigation shows that the DbGrid component also does not properly display a dBase table with a subset condition. This makes a lot of sense as:
DbCombo inherits from DbEdit, but contains a TPopupGrid which inherits from CustomDBGrid and DbLookup inherit directly from CustomDBGrid.

TUpdateRecordEvent is declared wrong in DBTables.pas

Description

Reported by Grant Corry

Currently:

TUpdateRecordEvent = procedure(DataSet: TDataSet; UpdateKind: TUpdateKind;

Should be:

TUpdateRecordEvent = procedure(DataSet: TBDEDataSet; UpdateKind: TUpdateKind;

The TUpdateRecordEvent is used in the TBDEDataSet class. It is meant to represent itself when called.

When connecting a DB control (i.e. DBGrid) to an Oracle database, the scroll bar does not proportion itself properly when the table/query being connected to has a large number of records

Description

Reported by T. Paul Szczesniak

This problem has not been independently confirmed yet. If anyone can reproduce/confirm it (or can't), please let us know!
To reproduce this problem simply connect a DB control to an Oracle database that has a table with more than 500 records.
I believe that this is a bug because the user cannot accurately reposition the list to the location that they want because the scroll bar will continue to reposition itself once the user tries to reposition it. In the native configuration for the Oracle BDE, the ROWSET SIZE is set to 20 rows and you will notice if you scroll using only the down arrow that the SQL hourglass will pop up every 20 rows. If this number is increased to encapsulate the expected number of rows then the program will crash due to memory problems.

Comment by Eivind Bakkestuen on 2 Feb 1999:
I believe the problem is caused by Oracle not supporting the concept of record numbers. I.e. it will work for Paradox, but not for Oracle and the like (other big-gun databases). Therefore it is not a Delphi problem.

Problem with IntelliMouse wheel

Description

Reported by Fulvio J. Castelli; checked by David Scheidt

I think I've encountered a bug in D4 involving the IntelliMouse wheel and the DBLookupComboBox component.

To reproduce:
Create a new form and put a DBLookupComboBox control on it. Link the list source/field to one table/field and the data source/field to a second table/field as you normally would. Run the program and drop down the combobox. Now move your mouse wheel. The program goes into some kind of infinite loop (only a Program Reset can get you back).
I'va also tried this with a regular combobox, but that seems to be ok.
Is this a known bug?

David Scheidt followed up:
This is not only a D4 bug. D3 does the exact same thing.

You can't type in anything in a dbLookupComboBox so that it will scroll to the next nearest character.

Description

Reported by Clarin Wong

I'm not too sure whether this is a bug in Delphi or it's just a constraint. It exists in Delphi Version 2.0 c/s, 3.0, 3.01 and 3.02.

You can't type in anything in a dbLookupComboBox so that it will scroll to the next nearest character. If you try to type in anything in a dbLookupComboBox whereby the ListField is not the key field in the table, you get an error Message "Cannot evaluate key or key does not pass filter condition". To be able to type in the first few characters is very helpful especially if you have a long list and you do not wish to scroll through the long list to find the one that you need. I know MS Access is able to do so but not in Delphi and I've no idea how to make it work.

To reproduce :

1. Drop a DBLookupComboBox, a TTable (at least 2 fields; one key field and the other maybe a description), a TDatasource and a TDatabase on a TForm.
2. Join the neccesary connections from the TDatasource to TTable and to TDatabase.
3. Select TDatasouce as the ListSource for the DBLookupComboBox.
4. Set the ListField as the Field description and set the KeyField as the Primary Key for that table.
5. Now, run your project and try to key in anything and you will get the message.

I hope someone will be able to help out here 'cause this is something that would come in handy in my various projects.
Thanks in advance

TBooleanField.GetAsString uses Bool instead of WordBool. This can make all boolean database fields display as 'true' even when the underlying value is false.

Description

Reported by Wolfgang Rohdewald; checked by Hallvard Vassbotn

If you recompile DB.Pas and are not careful about what compiler options you use, a bug in TBooleanField.GetAsString could surface and all boolean database fields will display as 'true' even when the underlying value is false.
Note: This bug will not appear if you use packages or if you use the precompiled DB.DCU from Borland. It will only appear if you recompile DB.PAS with Overflow checking on.
To reproduce the bug:

1. Start a new project in an empy directory
2. Drop a TTable, TDataSource and a TDBGrid on the form
3. Connect the components and connect the TTable to the RESERVAT.DB table in the DBDEMOS alias. Set Active to true. Resize the grid so that you can see the Paid column.
4. Run the project. Note than you can change the Paid column to false without problems.
5. Now copy DB.PAS from source\vcl into the project directory.
6. Change the compiler options so that Overflow checking is on.
7. Rebuild the project. Note that you might have to close and restart Delphi for it to recognize the DB.Pas in the project directory.
8. When you now run the program, all the Paid columns indicate True and you cannot change them permanently to false.
9. Turn off overflow checking and rebuild. Now the program works again.

The reason for this strange behaviour lies in the implementation of TBooleanField.GetAsString in Db.Pas. The original code looks like this:

function TBooleanField.GetAsString: string;
var
  B: Bool;
begin
  if GetData(@B) then Result := FTextValues[Boolean(B)] else Result := '';
end;

Note that the variable B is of the type Bool which is a 4-byte boolean and that a type-cast into Boolean is made before looking up the string representation in the FTextValues array. The GetData function will retrive the raw data from the database and the number of bytes it will read is determined by the GetDataSize method of TBooleanField:

function TBooleanField.GetDataSize: Word;
begin
  Result := SizeOf(WordBool);
end;

This shows that only 2 bytes of data are read into the 4-byte B variable. The upper word is thus garbage and could contain any value.
This is not a problem with the original DB.DCU or the package containing it because the unit was compiled with overflow checking off. In that case the generated code simply discards the garbage high-word of the B variable and the code works as expected.
However, when the overflow checks are turned on and the unit-recompiled, the generated code does consider the high-word when casting the B value into a Boolean. So any non-null garbage value (which always seems to be the case) will produce a true boolean result, even when the low-word is 0 (indicating a false value).

Solution / workaround

1. Use the default DB.DCU or package provided from Borland. This is compiled with the correct options.
2. If you need to recompile DB.PAS (because you have fixed some code in it), make sure that you compile it with the correct options. You can do this by inserting the following line at the top of DB.PAS:

{$Q-} { Overflow checking off }

Alternatively, just make sure Overflow checking is off in the project options whenever you recompile DB.PAS.
3. You can correct the code to use WordBool instead of Bool. At the same time you can remove the type-cast:

function TBooleanField.GetAsString: string;
var
  B: WordBool;
begin
  if GetData(@B) then Result := FTextValues[B] else Result := '';
end;

This code will work with all compiler options and the code is identical with the versions in D1 and D2 (they don't have this problem).
So the "bug" really boils down to Borland not documenting that DB.PAS must be compiled with overflow checking off. This problem should only occur for people that recompile their DB.PAS with overflow checking on.

Changing values doesn't change the Field values.

Description

Any attempts to change a value using documented techniques does not change the underlying field. For example:

    dbCheckBox1.Checked := True;

this will change the screen control, but not the underlying field. Similar results with:

    dbEdit1.Text := 'New';

This will seem to change it, but won't.

To observe these problems, set up a form with a ttable, a button, and one of each dbControl. Now, add code to the button click method to change each to another value. This will seem to work, but a Table1.Post call will show otherwise.
This seems to be a pervasive problem with the dbControls, that they can not be changed easily.

Solution / workaround

By Paulo Caetano
(Commenting on previous solution):
I have come up with a different workaround. Actually - and I hope you'll forgive my saying so - I don't think it's a bug; at least, it made sense to me (please read below).

My solution is:

     tabLixo.Edit;     // place TTable in edit mode
     DBEdit5.Text := 'Alter'; // Now it changes value

Although my version of Delphi 2 is not the latest (it's 2.17.53.0), the behaviour I experienced is the same as mentioned in the bug report. However, none of the workarounds worked for me, so...

The reason why I think it makes sense is the Help page for the Edit method. It says "Data-aware controls cannot modify existing records unless the dataset is in Edit mode."
Hope it helps.

TDBCombobox controls that are set to Style = csSimple had nothing in the display field

Description

Reported by Russell Kuster; supplemental information and fix by Tom Villars

The problem is easily created by starting a new app and placing 6 components - TDBComboBox, TTable, 2 TButtons, TNavigator and TDataSource on the form. Wire up the database-related components and connect TTable to any known physical table (a Paradox table in my case) and TDBComboBox to a field with non-blank data. Button1.OnClick has 1 line of code attached: DBComboBox1.Style := csSimple; while Button2.OnClick has DBComboBox1.Style := csDropDown;
After compiling, whenever Style = csDropDown, the text in DBComboBox1 works fine. But when Style = csSimple, the text is either blank, if csSimple was the beginning Style or the text is "frozen" on the value of the field at the time Style was switched from csDropDown to csSimple. Using TNavigator to scroll through the records does not affect the displayed text. (For what its worth, I've done this in both Win95 and NT4.0).

Explanation and fix:

By Tom Villars

The cause
in unit DBCtrls:

procedure TDBComboBox.DataChange(Sender: TObject);
begin
  if DroppedDown then Exit;  /* The DroppedDown Property ALWAYS returns
true when the Style = csSimple */
  if FDataLink.Field <> nil then
    SetComboText(FDataLink.Field.Text)
  else
    if csDesigning in ComponentState then
      SetComboText(Name)
    else
      SetComboText('');
end;

The Fix

unit StdCtrls;

function TCustomComboBox.GetDroppedDown: Boolean;
begin
  Result :=  ( Style <> csSimple ) 
                    /* If the style is simple then it can't be dropped */
         and LongBool(SendMessage(Handle, CB_GETDROPPEDSTATE, 0, 0));
end;

The Disclaimer
This "fix" will effect the behavior of all components derived from TCustomComboBox. Please be prepared to test all the other combo boxes in your app that have their styles set to csSimple, not just the DBComboBox.
The Advertisement
This Bug Fix brought to you by the programmers at:
Next-Generation Systems Inc.
800 230-6630

Enabled property doesn't work for all types of fields

Description

Reported by Bill Morgan

Put some DBEdit boxes on a form and link them to some table fields (I used a Paradox table). Put a button on the form which toggles the DBEdit boxes from 'enabled' to 'disabled'. The contents of the DBEdit boxes linked to Text or Date fields turn grey when disabled - BUT the contents of DBEdit boxes linked to Currency or Numeric fields do NOT turn grey when disabled.
Maybe I've made a mistake, but it looks like a bug to me.

Something goes wrong when the function MessageDlg is called in a DbEdit.Exit event.

Description

Reported by Samuel Natali Junior

When I call the function MessageDlg (or any other Message functions) in the DbEdit.Exit event, the second DbEdit field does not change the modifications in database.
This looks a bit like the same problem that is described in the next bug report

Solution / workaround

To resolve this problem, I insert this line:

procedure TForm1.DBEdit2Change(Sender: TObject);
begin
  dbEdit2.Field.AsString:=dbEdit2.Text;
end;

This workaround seems not to work very well. Comment by Chris Timmons:
When the example program is run normally, the bug appears. When I trace through the program and go into the VCL source code, the bug does not appear. I might run this one by the TeamB members on Compuserve and get their opinion.

The FixedColor property does not work.

Description

Reported by Hallvard Vassbotn

The FixedColor property of this component does not work as documented, and as it does work in TStringGrid and TDrawGrid. Changing this value at either design or run-time has no effect. It should set the color that is used to draw the fixed column and row backgrounds.

Solution / workaround

Hallvard Vassbotn originally reported this bug on the comp.lang.pascal newsgroup and included the following fix for the problem. I have not confirmed that it works, but it appears that it should.

Derive a new component from TDBGrid and add the following functionality:

{...unit declaration, uses clause...}
type
  TDBGridFix = class(TDBGrid)
  private
    procedure SetFixedFixedColor(Value: TColor);
    function  GetFixedFixedColor: TColor;
  published
    property FixedColor: TColor read GetFixedFixedColor 
                                write SetFixedFixedColor default clBtnFace;
  end;

  procedure Register;

implementation

procedure TDBGridFix.SetFixedFixedColor(Value: TColor);
begin
  inherited TitleColor := Value;
  inherited FixedColor := Value; { Not really needed, just to be safe }
end;

function TDBGridFix.GetFixedFixedColor: TColor;
begin
  Result := inherited TitleColor;
end;

procedure Register;
begin
  RegisterComponents('Data Access', [TDBGridFix]);
end;

end.

There is a bug in TDBGrid with column resizing

Description

Reported by Bill Florac

To see the bug, drop a DBGrid and point it to a datasouce/table. Activate the table so the columns are visible.
Now, drag the column with to a desired wdith. Now run the app and you will see the coulmn you just set is no longer the width you set.
The bug can be found in the DBGrids.pas file. This bug only exist in grids without a persistant column. As you can see, the VCL handles this with a TPassthruColumn object. If you examine this, you will see that the SetWidth and GetWidth procedures use different formulas for converting the pixel width to characters.

Solution / workaround

The fix (to SetWidth) is listed below:

procedure TPassthroughColumn.SetWidth(Value: Integer);
var
  Grid: TCustomDBGrid;
  TM: TTextMetric;
begin  
  Grid := GetGrid;
  if Assigned(Grid) then
  begin
    if Grid.HandleAllocated and Assigned(Field) and Grid.FUpdateFields then
    with Grid do
    begin
      Canvas.Font := Self.Font;
      GetTextMetrics(Canvas.Handle, TM);
  
// Borland Bug - fixed by wrf, 1-24-97  
// Getting width uses different formula than setting width  
// Since this is the GetWidth call  
//    Result := Field.DisplayWidth * (Canvas.TextWidth('0') - TM.tmOverhang) +
//      TM.tmOverhang + 4;  
  
// The SetWidth should be...
      Field.DisplayWidth := (Value - TM.tmOverhang - 4) div 
                            (Canvas.TextWidth('0') - TM.tmOverhang);
  
// Old SetWidth was..
//    Field.DisplayWidth := (Value + (TM.tmAveCharWidth div 2) - 
//                           TM.tmOverhang - 3) div TM.tmAveCharWidth;
  
    end;      
    if (not Grid.FLayoutFromDataset) or (cvWidth in FAssignedValues) then
      inherited SetWidth(Value);
  end
  else
    inherited SetWidth(Value);
end;

When you connect a Grid to a datasource, it appears to randomly come up with the error "Grid Index Out of Range" when it is created.
Solution by Brian Wheatley.
Comment by Peter Disselkoen.
Solution by Morgan Martinet.

Description

Solution / workaround

By Brian Wheatley

Well, you said someone should look into this problem, and I did.
I had the problem when running a master/detail report with QuickReport, so I dug in.
The problem is in the file Grids.pas (c:\....\Delphi 2.0\VCL\Source), line 2427. The function is TCustomGrid.MoveCurrent, and the line reads:

  if (ACol < 0) or (ARow < 0) or
     (ACol >= ColCount) or (ARow >= RowCount) 
  then
    InvalidOp(SIndexOutOfRange);

I changed the >= in both places to just > and recompiled. The problem went away, but I'm not 100% certain what side effects this might have later on.

I (Reinier Sterkenburg) have my doubts about this solution because it is not logical: Because a StringGrid has ColCount colums (and its indexing is off-by-one), a value in the range [0..ColCount-1] is valid. So including ColCount as an accepted value doesn't make sense to me. But if this cures the "Grid Index Out of Range" problem, it might be useful to some people.

Peter Disselkoen wrote me (us) the following explanation:

The stated solution sent by Brian Wheatley is not correct.
When the error "Grid Index Out of Range" occurs, it means that you made a programming error somewhere else in your code. I applied the solution of Brian and received "Access violations" exceptions. By examing the code written, I came to the conclusion that somewhere in the code I forgot to disable the controls (TTable.DisableControls, see page 57 Database Application Developer's Guide Version 2). If the controls are not disabled and you are walking through the code and forget to return to a valid record, then this error (Grid Index out of Range) occurs. This error did not occur in version 1.0 of Delphi.

Patrick Maartense wrote in addition to that:

I read the solution to the index out of range problem with the DBGrids. I *do* think that this is the solution; I had the same problem MANY times, with M/D grids and it turned out that these were being rescaled while data was loaded. Now the rescaling doesn't happen anymore before the tables have been loaded and opened completely, the problem has gone. It appears that it does have something to do with the row position of the cursor.

Solution:

By Morgan Martinet

Instead of patching the method TCustomGrid.MoveCurrent, I patched the method TCustomDbGrid.UpdateActive (in unit DbGrids):
Instead of the line:
if Row <> NewRow then
I wrote:
if (Row <> NewRow) and (NewRow < RowCount) then
and now it works perfectly!

The Scrollbar isn't always updated correctly.

Description

Reported by David Schuldenfrei

On a form, link a DBGrid to a DataSource and the DataSource to a Table (the table should contain more records than thye number of visible rows in the DBGrid). Set the Table to active. Add a Button to the form with the following OnClick event:

with Table1 do begin
   DisableControls;
   Close;
   Open;
   EnableControls;
end;

Run the application, go to the end of the table, and click the button.

The table is on the first record, but the grid ScrollBar stays at the end!
This bug is not serious, but sometimes (difficult to reproduce) there will be a "Grid Index out of range" error, and the DBAware components will not be synchronised.

Solution / workaround

(if you have the VCL source)
In the file DBGrids.Pas, in the implementation of the procedure TGridDataLink.LayoutChanged, before the final end; add the line

      inherited LayoutChanged;

If two lookup fields have keyfields of different data types (e.g. TSmallInt and TString), they produce a Variant conversion error when used successively.
Description and Solution by Jean-Pierre Joyal and François Bleau.
Giorgio Saviane pointed out that this is not really a bug. Turn off "break on exceptions" and the program runs fine.

Description

Reported by Jean-Pierre Joyal and François Bleau

The bug happens in DBGRIDS with two Lookupfields. If these lookup fields have keyfields of different data types (e.g. TSmallInt and TString), they produce a Variant conversion error when we use it successively.
To reproduce this bug, we send to you a complete project (This project is available on request; the bug is easily reproduced, RPS). In this sample, just try to modify data in the column DocDesc(TString keyfield) and after in the column CeduleDesc(TSmallInt keyfield) and you get the error.

Solution / workaround

We have a solution for it. We initalize to "null" the keyvalue of the corresponding TDBLookupListBox just before it assigned to it a new dataset. See the code in the new DBGRIDS file, in method

procedure TDBGridInplaceEdit.DropDown;
....
      FDataList.ListField := LookupResultField;
      //add this line to correct variant error with
      //two lookup of different data type
      //jpj and fb
      FDataList.KeyValue := Null;
      //normal code continue
      FDataList.ListSource := FLookupSource;
....

Changes made to a TDBMemo linked to a TStringField are discarded with Delphi 2 whereas they are correctly updated with Delphi 1.

Description

The following are the sections of DBCTRLS.PAS from D1 and D2.

Delphi 1 - DBCTRLS.PAS

procedure TDBMemo.CMExit(var Message: TCMExit);
begin
  if not (FDataLink.Field is TBlobField) then   {THIS WORKS}
.....

Delphi 2 - DBCTRLS.PAS

procedure TDBMemo.CMExit(var Message: TCMExit);
begin
  if FDataLink.Field is TBlobField then    {THIS DOES NOT WORK}
....

Clearing a Memo field in an Access table gives trouble

Description

Reported by Christian Daini; checked by Steve Ludmon

To reproduce the bug you need a Database of Type MSACCESS, with a field with DataType = Memo.

1. Start a new project.
2. Drop a TTable, a TDataSource, a TDBNavigator, a TDBMemo on the Form
3. Connect the Table1 to the Database of Type MSACCESS
4. Connect the DataSource1 to Table1
5. Connect the DBNavigator1 and the DBMemo1 to DataSource1
6. Set in DBMemo1 the property DataField = the field with DataType Memo
7. If you clear the Memo field (leave with no characters) and save the record, "strange" characters will show in the Memo field.

Comment by checker:
This problem occurs when we attempt to post a zero length string to an Access memo field. I tried to perform the same feat with the Data Manager which comes with VB4 and it simply wouldn't post the new data. The BDE does the post but the memo field is not allowed to be empty. I would have expected an exception to occur but instead we get a couple of rubbish characters in the field. This is definitely not the preferred situation!
I am sure it is a problem with the BDE so I will send it to Borland for their thoughts. In the meantime I have a work around for the problem - see below...

Solution / workaround

We can trap the condition immediately prior to posting and check for zero length as I have shown below. This fix checks for the erroneous condition and prevents it from occurring by converting the zero length string to a single space.

procedure TForm1.Table1BeforePost(DataSet: TDataSet);
begin
  if length(dbmemo1.text)=0 then
    table1.FieldByName('memo1').asstring := ' ';
end;

The Caption disappears after saving and reloading with the table inactive

Description

Reported by Dan Miser

To reproduce, place the following components on a form: A TDataSource, a TTable and a TDBText.
The DataSource is connected to the Table. The Table is connected to a valid Paradox table, and the DBText component is attached to a valid field in that table. If you save the form with the TTable's Active property set to false, close the form, and then re-load the form, the DBText component will have no Caption displayed.

TQuery can not handle table with more than 255 fields

Description

Reported by Normand Péladeau; checked by Hallvard Vassbotn

About a year ago, while working on a program using TQuery, I have found an important limitation. It is not possible to open a table with more than 255 fields despite the fact that both TQuery and TTable are supposed to handle up to 1024 fields in a single table.
When I mentioned this undocumented limitation to a Borland representative, he didn't believe me but after a short test he had to agree that this limitation was real. I also spoke with 3 other Borland representatives including Charles Calvert, and none of them were aware of this and were quite suprised to learn about the existence of this limitation.
I don't know whether this limitation has been solved in Delphi 2.0 or 3.0. A simple way to do it is to create a table with 260 fields and try to open it with a simple query within Delphi. (If I remember well, this BDE limitation also affect the Database Desktop program).

Comment from checker:
I can confirm this bug report - same behaviour in BDE 4.0, Delphi 3.0 build 5.53 running on NT 4.0 sp3. Database desktop will not even let you create a table with more than 255 fields. So this is a restriction. However, I do feel that if you create a table with more than 255 fields, you should seriously reconsider your database design.

Whenever you connect to a table you use an additional connection so one quickly runs out of available connections. TQuery does not have this problem.

Description

Reported by Dana Scott Kaufman and Usaya Kasaju

(DSK:) I consider this a bug. Borland might consider this as designed.
It appears on Delphi 1.0 and 2.0 with C/S database connection
If you design a Client/Server application with a single database object, in theory all connections go through this object. But when you use TTable objects linked to the TDatabase, each TTable opens its own connection to the server. This is a bad thing because servers are licensed by connection. The TQuery object does not open an additional connection. 7 TTables take up 7 connections on the server. If you have a ten connection license only one person can be on at a time.
I have verified this on MS SQL Server and Informix.

(UK:) Whenever we connect to a table we get an additional connection so if we happen to connect many tables there we get an error message saying 'max. no of users connection'.

In the sp_conifguration of SQL Server we increased the no from 15 to 50 ....Still we are getting the problem.

TTable.Post is not enough to update the .db file

Description

Reported by Tom Gruintjes; confirmed by Hugo Gomez

Add a call to DbiSaveChanges where you want to save your changes:

uses DbiProcs;

  ...
  DbiSaveChanges(MyTable.Handle);
  ...

Additional comment by Cindy Kircher:
The fix states to use dbiSaveChanges. This does not seems to actually commit the data to the .db file either. We have been testing this with a floppy drive and found the following. First Activate the database then Post a record. Without the dbiSaveChanges or closing the database the .db file does not contain any records. (Checked on a different computer) With dbiSaveChanges but not closing the database, the file contains a blank record. The only way we have been able to get the actual data posted to the database is to close it.

I understand that there are 2 levels of caching being done (BDE and Windows file system). dbiSaveChanges is for the BDE but I have not found a 16 bit API call to flush the file system buffers. In 32 bit the call is FlushFileBuffers.

TTable cannot access Paradox tables on Lantastic 6.0 servers.

Description

Borland has acknowleged an incompatibility between BDE/IDAPI 1.3 (shipping with Delphi) and Lantastic 6.0 network operating system. This bug prevents access to Paradox tables that are located on a redirected server drive. This affects not only the Delphi data-aware components, but Database Desktop as well. Attempting to access the table usually results in an error message similar to "Not initialized for accessing network files."

Solution / workaround

The only known workaround is to use a format other than Paradox.