Hi,

It seems to me that dbsys does something strange with BLOBs and maybe
it can be optimized (I know I have the code, I just noticed the problem
and thought it would be good to mention it here first). The thing is:

I am having a table with blobs, at home, which I access from the office
with dbsys, via internet. Some BLOBs are rather big, 10-20MB. So, when
I double click the field, it takes a lot of time until the box with 2
buttons (import-export) shows up. I take it it downloaded the BLOB, but
heck, after I click export (filename dialog, ok), it takes once again a
whole lot of time ... like is downloading the BLOB one more time. This
is the first problem.

The second problem is somehow related. At the same time dbsys is
downloading those big BLOBs, I am running another application of mine,
which also connects to home. When dbsys is downloading the big blobs,
the second application is almost dead, running exceedingly slow. I know
the server is multithreaded. Why is the second app so slow?


My configuration is: client server, 4.25b1 on both locations, xp-pro on
both locations, lots of ram, lots of hdd.

--

regards,

Lucian

> So, when I double click the field, it takes a lot of time until the

That seems to be the line, main.pas, where the label.caption showing
BlobSize is set (TMainForm.WindowGridDblClick).

Another thing ... I am not a fan of QuickReport, hence I never install
that crap. It would be nice to have conditional symbols in the dbsys
project to allow people to compile the project when they don't have
said crap...


regards,

Lucian

Lucian,

<< That seems to be the line, main.pas, where the label.caption showing
BlobSize is set (TMainForm.WindowGridDblClick). >>

The TDataSet architecture is such that Blobs are completely-opened in order
to obtain their size.  We tried working around this in EDB, and it just
wasn't possible.  Therefore, the entire BLOB has to be read down into the
client from the server in order to obtain the size.

<< Another thing ... I am not a fan of QuickReport, hence I never install
that crap. It would be nice to have conditional symbols in the dbsys project
to allow people to compile the project when they don't have said crap... >>

That's not high on our list right now, but I will certainly add it to our
list of items to address.

--
Tim Young
Elevate Software
www.elevatesoft.com

Lucian,

<< The second problem is somehow related. At the same time dbsys is
downloading those big BLOBs, I am running another application of mine,
which also connects to home. When dbsys is downloading the big blobs, the
second application is almost dead, running exceedingly slow. I know
the server is multithreaded. Why is the second app so slow? >>

What kind of bandwidth do you have connected to the server ?  Is the up-link
(or outbound) speed fairly slow ?

--
Tim Young
Elevate Software
www.elevatesoft.com

> What kind of bandwidth do you have connected to the server ?  Is the
> up-link (or outbound) speed fairly slow ?

At the office it's fast, probably T1. At home (where the server runs) I
am on cable, a 1Mb line. But the thing is, I was monitoring the network
usage here (at the office), with a sniffer and I saw both connections:
the first one (dbsys-->dloading stuff) was rolling bytes fast, while
the second one (the app logging in) was very slow. I would've expected
the speed to be 50-50, or close.

thx,

Lucian

> The TDataSet architecture is such that Blobs are completely-opened in
> order to obtain their size.

Oh, I see. I thought the .blb file holds the blobs, while the actuall
field in the .dat table will hold position and size of the blob, thus
rendering unnecesary to read the blob to get its size.

> it just wasn't possible.  Therefore, the entire BLOB has to be read
> down into the client from the server in order to obtain the size.

I understand that and I was hoping the field would know it has got the
blob second time so it wouldn't download it again.


Anyway, it's a minor issue for me, I just noticed it in dbsys only. It
seems I managed to avoid double-reads in my blob based application.


>> ... QuickReport
>
> That's not high on our list right now, but I will certainly add it to
> our list of items to address.

Please do add it, and thanks
Its' also minor issue for me since it happens just very few times a
year that I have the need to compile dbsys.


--
Regards,

Lucian

Lucian,

<< Oh, I see. I thought the .blb file holds the blobs, while the actuall
field in the .dat table will hold position and size of the blob, thus
rendering unnecesary to read the blob to get its size.>>

You're mixing DBISAM up with the TDataSet architecture (Borland).  We don't
control how the TDataSet stuff works, and TBlobField is in the db.pas unit
as part of the TDataSet architecture, and it dictates that a BLOB be opened
in its entirety into a stream in order to read the size of the stream.

<< I understand that and I was hoping the field would know it has got the
blob second time so it wouldn't download it again. >>

The only way to do that would be to cache the BLOBs along with the rows,
which EDB does but DBISAM does not.

--
Tim Young
Elevate Software
www.elevatesoft.com