I've been debugging a progect over the past few weeks, and came up with a problem that I can't figure out.  I have a TDBISAMTable with a list of employee names, roles, email, etc in
it.  I have a few DBlookUp combo boxes which read the Employee table and access the Employee Name field.  However, once I expand the DBLookUp combobox to display the
employee's names, and then go back to the original table, only the employee name field is shown.  I have to restart the program to view all the fields again.  Any ideas here?

Thanks!

Nate,

<< I've been debugging a progect over the past few weeks, and came up with a
problem that I can't figure out.  I have a TDBISAMTable with a list of
employee names, roles, email, etc in it.  I have a few DBlookUp combo boxes
which read the Employee table and access the Employee Name field.  However,
once I expand the DBLookUp combobox to display the employee's names, and
then go back to the original table, only the employee name field is shown.
I have to restart the program to view all the fields again.  Any ideas here?
>>

What steps programatically are you taking when you do:

"expand the DBLookUp combobox to display the employee's names"

?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<What steps programatically are you taking when you do:

"expand the DBLookUp combobox to display the employee's names"?
>>

I use InfoPower look up dialogs (TwwDBLookUp).  These have properties to select the lookup table and the lookup field.  I tried another DBlookUp dialog but the same thing happened,
so it is not the InfoPower dialog.

Basically, once I expand the lookup combobox and go back to the grid on another form, only the lookup field is displayed in the grid.

Nate,

Sounds like you are sharing a table cursor between the grid
and the DBLookup. The DBLookup is a grid and is most likely
changing the Visible properties of the fields to limit what
you are seeing. If both grids are attached to the same
cursor (same dataset & fields), changing the visible
property of a field will affect both. I would suggest that
you create another cursor for use in the DBLookup. I don't
believe there will be much overhead since the engine will
already have the table opened and is efficient at managing
multiple cursors.

HTH,

Sean

Nate wrote:
> Tim,
>
> <<What steps programatically are you taking when you do:
>
> "expand the DBLookUp combobox to display the employee's names"?
>
>
> I use InfoPower look up dialogs (TwwDBLookUp).  These have properties to select the lookup table and the lookup field.  I tried another DBlookUp dialog but the same thing happened,
> so it is not the InfoPower dialog.
>
> Basically, once I expand the lookup combobox and go back to the grid on another form, only the lookup field is displayed in the grid.
>

Sean,

I'm fairly new to using Delphi (only about 4 months or so).  What exactly do you mean by changing the table cursor.  Is this a property that is set in the DBLookUp or the table?  Or
there code that has to be added?

Nate


Sean McCall <NoSpam@nowhere.com> wrote:

>Nate,

>Sounds like you are sharing a table cursor between the grid
>and the DBLookup. The DBLookup is a grid and is most likely
>changing the Visible properties of the fields to limit what
>you are seeing. If both grids are attached to the same
>cursor (same dataset & fields), changing the visible
>property of a field will affect both. I would suggest that
>you create another cursor for use in the DBLookup. I don't
>believe there will be much overhead since the engine will
>already have the table opened and is efficient at managing
>multiple cursors.

Nate,

Each TDBISAMTable or TDBISAMQuery (or any TDataSet
descendant) is a "cursor" (allows you to navigate records).
You can open 5 DBISAMTable objects all pointing to the same
physical table and each of these cursors will have a
separate field list and maintain a separate buffer and
record position. The engine will only open the physical file
once and will keep track of all your cursors for you. In
your case, you would need to create a second TDBISAMTable to
be used by the lookup combo and point it to the same
physical table as the one used by the grid. This way when
the DBLookup sets the visible properties of the fields it
won't change the visible properties of the fields used by
the TDBISAMTable linked to the grid. Since you only need 2
fields out of the table for the lookup (plus any primary
key) you could create the table with only the fields that
the lookup needs to display the information and this will be
faster for buffering and navigating records.

HTH,

Sean


Nate wrote:
> Sean,
>
> I'm fairly new to using Delphi (only about 4 months or so).  What exactly do you mean by changing the table cursor.  Is this a property that is set in the DBLookUp or the table?  Or
> there code that has to be added?
>
> Nate
>
>
> Sean McCall <NoSpam@nowhere.com> wrote:
>
>
>>Nate,
>
>
>>Sounds like you are sharing a table cursor between the grid
>>and the DBLookup. The DBLookup is a grid and is most likely
>>changing the Visible properties of the fields to limit what
>>you are seeing. If both grids are attached to the same
>>cursor (same dataset & fields), changing the visible
>>property of a field will affect both. I would suggest that
>>you create another cursor for use in the DBLookup. I don't
>>believe there will be much overhead since the engine will
>>already have the table opened and is efficient at managing
>>multiple cursors.
>
>
>

Sean,

That worked perfectly! Thanks!!  I didn't think it would be that simple.

Nate


Sean McCall <NoSpam@nowhere.com> wrote:

<Nate,

<Each TDBISAMTable or TDBISAMQuery (or any TDataSet
<descendant) is a "cursor" (allows you to navigate records).
<You can open 5 DBISAMTable objects all pointing to the same
<physical table and each of these cursors will have a
<separate field list and maintain a separate buffer and
<record position. The engine will only open the physical file
<once and will keep track of all your cursors for you. In
<your case, you would need to create a second TDBISAMTable to
<be used by the lookup combo and point it to the same
<physical table as the one used by the grid. This way when
<the DBLookup sets the visible properties of the fields it
<won't change the visible properties of the fields used by
<the TDBISAMTable linked to the grid. Since you only need 2
<fields out of the table for the lookup (plus any primary
<key) you could create the table with only the fields that
<the lookup needs to display the information and this will be
<faster for buffering and navigating records.

Sean,

<< Each TDBISAMTable or TDBISAMQuery (or any TDataSet descendant) is a
"cursor" (allows you to navigate records). You can open 5 DBISAMTable
objects all pointing to the same physical table and each of these cursors
will have a separate field list and maintain a separate buffer and record
position. The engine will only open the physical file once and will keep
track of all your cursors for you. In
your case, you would need to create a second TDBISAMTable to be used by the
lookup combo and point it to the same physical table as the one used by the
grid. This way when the DBLookup sets the visible properties of the fields
it won't change the visible properties of the fields used by the
TDBISAMTable linked to the grid. Since you only need 2 fields out of the
table for the lookup (plus any primary
key) you could create the table with only the fields that the lookup needs
to display the information and this will be faster for buffering and
navigating records. >>

Wow, that was fantastic - I couldn't have done it better myself.

--
Tim Young
Elevate Software
www.elevatesoft.com

I agree. I bookmarked it.

Jerry

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:0E1A0DEE-4157-4BD7-B124-19CE82DFC535@news.elevatesoft.com...
| Sean,
|
| << Each TDBISAMTable or TDBISAMQuery (or any TDataSet descendant) is a
....
|
| Wow, that was fantastic - I couldn't have done it better myself.
|
| --
| Tim Young
| Elevate Software
| www.elevatesoft.com
|
|

Tim


It was also one of the delights in moving from Paradox. Three files per table - one handle per table no matter how many cursors (or sort of) compared to 2 + n files with n depending on the indices and a handle for each cursor (or something like that)

Roy Lambert