Bob,
Does the use of DBPix get around the 2K limit for a record in JET 4,
*without* the use of a pointer to point to data stored external to the table?
If your answer is no, then I stand by my original statements. You stated:
" I am not aware of any data loss whatsoever, and the minute number
of database corruptions has been unrelated to the use of binary, easily
recoverable, and typically caused by programming errors or general
Access glitches that apply equally to systems that use binary or don’t."
I have personally helped many people over the years with corrupted records
that included a memo datatype. The memo field only included text, so I don't
think we are talking about OLE Embedding here. Something apparently caused an
interrupted write operation, or some other glitch caused a pointer to the
external data to be lost. In all your years of using Access, you state that
you've never experienced this type of data corruption? I find that amazing,
if I understand you correctly. Your experiences of such reliability would
mean that the likelihood of anyone ever experiencing the issue described by
Access MVP Allen Browne on this page would be practically non-existant. See
the section titled "Symptom: Memo field contains strange characters" here:
http://allenbrowne.com/ser-47.html
Allen included the following statement:
"Access uses a pointer to another location for the data in large fields
(memo, hyperlink, or OLE Object). If the pointer is written incorrectly, the
field displays garbage."
So, my question to you is does the use of DBPix mean that a pointer will be
included to the data? If the answer is yes, then I consider this to be an
inefficient mechanism that can certainly lead to increased chances of
corruption, especially in the data is located on a file server (ie. a network
is involved).
...and I neither mentioned nor advocated our product,...
The fact that you included a link in your signature to your company, along
with the name of the product, would be consided advocating by many people,
including myself. It certainly is mentioning the product:
_______________________________________________________
http://www.ammara.com/ ;
Image Handling Components, Samples, Solutions and Info
DBPix 2.0 - lossless jpeg rotation, EXIF, asynchronous
The links you mention (Tony, Arvin, Stephen, Larry etc) are present
because they are excellent resources...
No disagreement there!
As requested, we don’t publish comments from MVPs etc, since it could
imply an endorsement or commercial association.
I'd be surprised if any Access MVP would feel too concerned about publishing
a review, good or bad, about any product that is intended for use with
Access. If the product is good, and can help users work around problems, why
would they have any hesitation in saying so? A person can certainly include a
statement indicating whether or not they have any commercial association with
the product in question. As you know, I do not have MVP but I have
recommended certain products in newsgroup posts in the past, specifically
FMS's Total Access Analyzer (this product is well worth the $299 cost) and
Splitter for Microsoft Access for helping to split difficult name data ($39).
If, sometime in the future, I am awarded MVP status, I would hope that I
wouldn't be under any pressure to stop suggesting very useful software.
At this time there aren’t any reviews of our product in the publications you
mention, most likely because we haven’t submitted the product to those
editors for review, but thanks for the ideas.
Kind of seems like a "no-brainer" to me, to submit your product for review
not only to these publications, but also to various Access user groups.
You're welcome.
Tom
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
:
My reason for replying to your post is that statements like ‘Access/Jet is
inefficient at storing images’ are so frequent here that many people actually
believe just that, without understanding that it only applies to a specific
technique, or that there is another way which is far more suitable, and is
indeed the simple and obvious way to do it (storing the binary directly in a
binary field, often what people actually assumed they were doing when they
used OLE Embedding anyway).
Jet is not inefficient at storing images, Access is not inefficient at
storing images, OLE Objects are not inefficient at storing images. What
*can* be inefficient, is OLE Embedding, a technique that is now becoming
defunct in this context since Microsoft withdrew the typical OLE Server used
for images.
I don’t believe that it is the right place to discuss how our product is
marketed, and I neither mentioned nor advocated our product, but I will try
to answer your questions. If you have more, I suggest that this goes
offline. I am here for technical discussion, not explaining why we link to
some site or other.
I even noticed 4 links at the bottom of this page:
The links you mention (Tony, Arvin, Stephen, Larry etc) are present because
they are excellent resources that are extremely relevant to our site’s
content, and therefore likely to be of specific interest to visitors
researching the subject. Several of them even include non-commercial
alternatives to our product, allowing
our visitors to make an informed choice from the available options. Arvin
reviewed and tested DBPix for inclusion in The Access Web’s Products page,
and occasionally suggests it as a solution here on Usenet (thanks again
Arvin).
I see a lot of testimonials from people I've never heard of on this page
As requested, we don’t publish comments from MVPs etc, since it could imply
an endorsement or commercial association. The comments are from users who
feel strongly enough to voice their views publicly, but there are a lot of
Access developers out there, so it’s hardly surprising that you haven’t heard
of any of this little subset of them.
I can't say that I've ever seen anything in publications
At this time there aren’t any reviews of our product in the publications you
mention, most likely because we haven’t submitted the product to those
editors for review, but thanks for the ideas.
I stand by my statement of increased chances of corruption with any OLE …
I also stand by mine, i.e. in nearly 10 years of working every day with
Access/Jet in a binary role, with thousands of customers on disparate
systems, it has been an exceptionally reliable and efficient storage
mechanism, provided standard Access design guidelines are followed (and OLE
Embedding avoided). I am not aware of any data loss whatsoever, and the
minute number of database corruptions has been unrelated to the use of
binary, easily recoverable, and typically caused by programming errors or
general Access glitches that apply equally to systems that use binary or
don’t.
