VB Forum / Win API / September 2008

Theoretically, yes.  But the complexity of doing it might not be better than
just using DAO or ADO if you've already managed to accomplish what you need
using either of those.

I assume by "extra burden", you mean ensuring either DAO or ADO is installed
on the target system. There should be few, if any, issues in that regard for
ADO as it's already on any Windows 2000 or higher system. Just make sure you
use a low enough version of ADO during your development. If you use ADO 2.5,
you should be OK for Windows 20000 or greater.  If WinXP is going to be the
lowest OS you're going to support, you can use ADO 2.6. You could probably
even go with ADO 2.8 and not have too many issues of users not having that,
especially if the users are pretty good at obtaining updates from Microsoft
(either via Automatic Updates or regularly going to Windows Update or
Microsoft Update).

If that's not what you mean by extra burden, then please clarify.

See if this is helpful....
http://vbnet.mvps.org/code/file/combine1.htm

LFS

How many pictures do you expect to store? Tens of thousands or more? If so,
use ADO. You probably have a search feature, and will be asked to add "sort
by" feature. In this case it will take you a long time to duplicate SQL
functionality.

Whether you choose ADO or your own, store the picture separately, and store
the relative path to the file name. GetTempFileName() creates a unique file
with length 0 bytes and close it before returning, so you can open/create
the file and save your picture. It uses ".tmp" extension, so rename the file
first(Using Name Statement), then write to it.

One reason to store the picture separately is that reading small number of
bytes repetitively is slow, because there is an overhead by the file system,
even if you use the API directly. In ADO with indexing this is less of a
factor, because the index will help speed up the process. In your own, you
have to read the text part(few bytes), then skip the picture to the next
text(or another file, if it's 1 file per picture). If you are reading 100
bytes or more at a time, the speed would be acceptable. For 4K at a time,
you get very close to the highest speed possible.

Also, VB6 is limited to 2GB per file, if you try to exceed this, you get a
run time error. You can use the API for more than 2 or 4 GB per file.

Finally, if you choose to make your own, use a class or functions and
isolate the higher levels in your application from the implementation
details of how pictures and their data are stored. So in case you want to
move to ADO, you don't have to rewrite a lot of code to do it.

  I would. It sounds like what you need is fairly simple,
so you just need to define a marker to mark the beginning
and end of the image. Or if you need to do something
more complex than that you can do what most other
file formats do: Design a simple file header with data
stored at specific offsets. For instance, the first 4 bytes
might identify your custom file type, the next four might
provide the offset of the first byte of the image. The next
four could proivide the length of the image bytes. Etc.