Tim:

I've just updated to EDB 2.02 b12, Unicode, Delphi 2009 Pro.  I'm now unable to navigate rows in a DevExpress cxGrid.  It does work in a
standard TDBGrid.  I seem to recall a similar issue a while back that was fixed.

Any thoughts?  Thanks.

Greg Bishop

Greg,

<< I've just updated to EDB 2.02 b12, Unicode, Delphi 2009 Pro.  I'm now
unable to navigate rows in a DevExpress cxGrid.  It does work in a standard
TDBGrid.  I seem to recall a similar issue a while back that was fixed. >>

It could be a Unicode issue with the grid.  What version of the cxGrid are
you using ?  Also, do you get the same issue regardless of the GridMode
property setting ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim:

I'm using their latest release:  v1.43 release on April 9, 2009 (aka ExpressQuantumGrid Suite v6.43).

I'm using the default, GridMode := False.  However, it appears to be working as expected if I set GridMode := True.

Greg

Greg,

<< I'm using their latest release:  v1.43 release on April 9, 2009 (aka
ExpressQuantumGrid Suite v6.43).

I'm using the default, GridMode := False.  However, it appears to be
working as expected if I set GridMode := True. >>

Sorry for the delay in getting back to you on this.

I can't reproduce this here with the latest 6.43 grid and B12.  Is there a
particular table with a particular index order that you're using ?  If so,
could you email me the database catalog/table files ?

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim:

I couldn't reproduce this issue at first in a simple project.  Then I set the KeyFieldNames property of the DBTableView in the cxGrid and the
problem appeared.  I'm using a query that references the Contact table (Just "SELECT * FROM Contact").  KeyFieldNames was set to "ContactID".  
ContactID is a computed column.

I've e-mailed a sample project and the most-recent database backup that demonstrates this issue.

Greg

Greg,

I am pretty sure the KeyFieldNames in a DevEx grid must refer to a
physical column in the dataset. The purpose is to allow the dataset
cursor to remain synchronized with the active row of the in-memory data
for the grid. The grid most likely uses the TDatset.Locate method to
move the dataset cursor and this would almost certainly require a
physical field.

The query you listed only includes physical fields in the table and so
there can be no field named ContactID in the result set. If you have
added it as a calculated field, it could not be used by the locate method.

Sean

Greg Bishop wrote:
> Tim:
>
> I couldn't reproduce this issue at first in a simple project.  Then I set the KeyFieldNames property of the DBTableView in the cxGrid and the
> problem appeared.  I'm using a query that references the Contact table (Just "SELECT * FROM Contact").  KeyFieldNames was set to "ContactID".  
> ContactID is a computed column.
>
> I've e-mailed a sample project and the most-recent database backup that demonstrates this issue.
>
> Greg
>

Sean:

The ContactID field does have an index and, although calculated, it is the primary key.  That's one of the neat things about ElevateDB ... it'll allow
indices on calculated fields.

This worked in a past version of ElevateDB, just not the current release.

Sean:

I thought I'd expand on this a little bit.

I have two other fields:  ID (autoincremented integer) and DBID (an integer).  This isn't the case yet, but my application might eventually get
installed at more than one location.  Each installation would have a unique DBID (Database ID) that gets populated into the DBID field during eac
row insert via a trigger.  Each installation would also autoincrement the ID field beginning at 1.  ContactID (in the case of the Contact table) is
calculated from ID and DBID; it is also defined as the primary key.  Therefore, each installation can have duplicated autoincremented IDs, but
because of the calculated ContactID, it will have a unique primary key.  This way I don't need compounds keys, which I don't like using.

This scheme was proposed by others (Tim, I think) in these newsgroups ... just to give credit where it is due.  It is intended to make (eventual)
replication easier without needing GUIDs or a more complex scheme to ensure unique primary keys.

Greg

Didn't know it could do that! I was thinking calculated fields in the
dataset. Sorry - have no idea what could be the issue.

Sean

Greg Bishop wrote:
> Sean:
>
> The ContactID field does have an index and, although calculated, it is the primary key.  That's one of the neat things about ElevateDB ... it'll allow
> indices on calculated fields.
>
> This worked in a past version of ElevateDB, just not the current release.
>

Greg,

Seems like a great way to get uniqueness without a guid. Out of
curiosity, what kind of field are you using to hold the ContactID?

Sean
Greg Bishop wrote:
> Sean:
>
> I thought I'd expand on this a little bit.
>
> I have two other fields:  ID (autoincremented integer) and DBID (an integer).  This isn't the case yet, but my application might eventually get
> installed at more than one location.  Each installation would have a unique DBID (Database ID) that gets populated into the DBID field during eac
> row insert via a trigger.  Each installation would also autoincrement the ID field beginning at 1.  ContactID (in the case of the Contact table) is
> calculated from ID and DBID; it is also defined as the primary key.  Therefore, each installation can have duplicated autoincremented IDs, but
> because of the calculated ContactID, it will have a unique primary key.  This way I don't need compounds keys, which I don't like using.
>
> This scheme was proposed by others (Tim, I think) in these newsgroups ... just to give credit where it is due.  It is intended to make (eventual)
> replication easier without needing GUIDs or a more complex scheme to ensure unique primary keys.
>
> Greg
>