I need to have my server send blobs to a client. I would like to do
this so that the client doesn't receive the contents of any blob until
those contents are specifically requested. I'm using TDBISAMQuery
components for the data transfer. I have a primary table on display
with a lot of controls that allow for user-defined queries.

I could put the blobs in a separate table linked by a key to the
primary table, and then run a separate query on request, but I'm
wondering if there might be a better way to do this. Any suggestions
would be welcome.

TIA, Glynn

Glynn Owen wrote:

> I need to have my server send blobs to a client.

I use ClientDataSets with / Dbisam so I normally fetchBlobs only when I
request them, but in your case why not just do a separate query to
fetch the blob forthe current record when the end-user requests it?

--
David Farrell-Garcia
Whidbey Island Software, LLC

David Farrell-Garcia wrote:

> Glynn Owen wrote:
>
> > I need to have my server send blobs to a client.
>
> I use ClientDataSets with / Dbisam so I normally fetchBlobs only when
> I request them, but in your case why not just do a separate query to
> fetch the blob forthe current record when the end-user requests it?


No compelling reason. It's just that in reading over the documentation,
I have the impression that what I'm trying to do may be a feature of
DBISAM that I don't yet understand, so I thought I would ask.
Otherwise, your suggestion does provide an alternative to my own that
has the advantage of not requiring another table.

Thanks,
Glynn

Data in blobs aren't sent to the client unless there is a data-aware
control (dbgrid, dbmemo control, dbpicture control, etc.) that is
expecting them or the blob's field contents are specifically accessed.

Glynn Owen wrote:
> I need to have my server send blobs to a client. I would like to do
> this so that the client doesn't receive the contents of any blob until
> those contents are specifically requested. I'm using TDBISAMQuery
> components for the data transfer. I have a primary table on display
> with a lot of controls that allow for user-defined queries.
>
> I could put the blobs in a separate table linked by a key to the
> primary table, and then run a separate query on request, but I'm
> wondering if there might be a better way to do this. Any suggestions
> would be welcome.
>
> TIA, Glynn

Glynn,

<< I need to have my server send blobs to a client. I would like to do this
so that the client doesn't receive the contents of any blob until those
contents are specifically requested. I'm using TDBISAMQuery components for
the data transfer. I have a primary table on display with a lot of controls
that allow for user-defined queries. >>

Jason is correct - this is how DBISAM works by default.

--
Tim Young
Elevate Software
www.elevatesoft.com

Jason Lee wrote:

> Data in blobs aren't sent to the client unless there is a data-aware
> control (dbgrid, dbmemo control, dbpicture control, etc.) that is
> expecting them or the blob's field contents are specifically accessed.
>
> Glynn Owen wrote:
> > I need to have my server send blobs to a client. I would like to do
> > this so that the client doesn't receive the contents of any blob
> > until those contents are specifically requested. I'm using
> > TDBISAMQuery components for the data transfer. I have a primary
> > table on display with a lot of controls that allow for user-defined
> > queries.
> >
> > I could put the blobs in a separate table linked by a key to the
> > primary table, and then run a separate query on request, but I'm
> > wondering if there might be a better way to do this. Any suggestions
> > would be welcome.
> >
> > TIA, Glynn


I am using a DBGrid. From what you (and Tim) said, it may be a workable
plan to -

a) disconnect the query from the datasource of the grid.
b) run the query
c) locate the blob field and set its visible property to FALSE
d) reconnect the query to the datasource

Hopefully, this will leave the blob field accessible by code, but not
accessed by the grid.

Guess I'll give it a whirl and see what happens.

Thanks for your help,
Glynn

-or-

if it is logistically feasible, do not include the blob field in the set
of fields that are displayed in the dbgrid

Glynn Owen wrote:
> I am using a DBGrid. From what you (and Tim) said, it may be a workable
> plan to -
>
> a) disconnect the query from the datasource of the grid.
> b) run the query
> c) locate the blob field and set its visible property to FALSE
> d) reconnect the query to the datasource
>
> Hopefully, this will leave the blob field accessible by code, but not
> accessed by the grid.
>
> Guess I'll give it a whirl and see what happens.

Glynn,

<< I am using a DBGrid. From what you (and Tim) said, it may be a workable
plan to - >>

Actually, Jason is correct again - the easiest method is to simply not
include the BLOB field in the list of fields used by the grid control.  That
will prevent the grid from doing anything with the BLOB field.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Glynn,
>
> << I am using a DBGrid. From what you (and Tim) said, it may be a
> workable plan to - >>
>
> Actually, Jason is correct again - the easiest method is to simply
> not include the BLOB field in the list of fields used by the grid
> control.  That will prevent the grid from doing anything with the
> BLOB field.

Yes, but that seems to be throwing out the baby with the bathwater. I'm
trying to avoid doing a second query just to fetch the blob field.

Thanks for your help,
Glynn

--
http://realthinclient.com

You can use the same query, just don't display the blob field in your
grid initially....(hint: double-click the dbgrid at design-time to get a
field list)

Glynn Owen wrote:
> Yes, but that seems to be throwing out the baby with the bathwater. I'm
> trying to avoid doing a second query just to fetch the blob field.