> From what I seem to recall of this issue its only empty .blbs that
> get zapped so you have an easy option.

What a good thought! Why not just automatically create a record in the
table with a big blob? The record would obviously have to be ignored, but
a field called "ignore" could be set to make this happen. This would fit
the unable to change scenario nicely.

/Matthew Jones/

Sam:

Sorry for the delay in replying back but I have been out of town at a
conference since last Wednesday and didn't have internet access at all.

<<We have carefully walked the path of renaming the blb files, and we
<<just can't. It is simply too late for us.

Understood and only you have the information that can ultimately decide
that for yourself.

<<The next option we see is to instrument dbrepair itself to do this.
<<For us, this is a proper solution. Database damaged? Do a repair.

However the database isn't "damaged". Another program deleted a file,
much as if a malicious and/or unknowing user might.

<<That works in concept, and in practice. (Doesn't matter what caused
<<the damage, could be anything.)

Once again...the database isn't damaged. It is not a DBISAM issue. A
file is missing...deleted by another process.

>>We just want DBISAM to create a 'known good and valid, true
>>DBISAM' blb for a given table.

<<Is it possible to open a paid or hourly support incident to
<<facilitate such a feature in DBISAM ?

Sorry, I can't answer that. You would have to contact Tim directly and
negotiate any type of custom programming options with him.

You've been given a lot of good options and it would seem to me that
one of them should work for you based on your situation.

--
Regards,
Jan Ferguson [Team Elevate]

Greetings All!!!

We are looking for a way to recreate at run time a missing .blb file.

The missing .blb is always empty, so no data is lost.


The problem we hit is that the DBREPAIR function in DBISAM fails to repair the issue... so
we are stuck!


We have looked at empty .blb files, and are not sure we can reliably recreate them. They
appear to be unique in some way (e.g. there appears to be no universal, empty .blb).

Storing our .blb files is not possible for a number of reasons (for one, there are a lot
of them!).


Please advise how we can address this in code.

Thanks!

Rafael,

<< Please advise how we can address this in code. >>

This was covered in this very thread that you started:

http://www.elevatesoft.com/newsgrp?action=openmsg&group=5&msg=60350&page=1#msg60350

--
Tim Young
Elevate Software
www.elevatesoft.com

That is this thread, right? (Seems to be.)

Can you point me to the relevant post? (or copy it). I reviewed the thread, and did not
see steps to do this.

Thanks!!!




"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Rafael,

<< Please advise how we can address this in code. >>

This was covered in this very thread that you started:

http://www.elevatesoft.com/newsgrp?action=openmsg&group=5&msg=60350&page=1#msg60350

--
Tim Young
Elevate Software
www.elevatesoft.com

<< That is this thread, right? (Seems to be.)

Can you point me to the relevant post? (or copy it). I reviewed the thread,
and did not see steps to do this. >>

You can't, which is what the thread covered.  You keep posting the same
messages about the same issue, and don't seem to understand or listen to
what my responses are.

There is nothing that we can do about the fact that some anti-spyware
software improperly deletes our .BLB files.  This has been discussed at
length.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

A follow on question...

Is there a DBISAM function we can use that will tell us that the .blb is missing?

Or, to put another way, when a table fails to open, is there a way to ask that table if it should have a .blb? (we could then look on the file system
to see if the .blb is there).


Thanks to everyone for great input on this. We have loads of suggestions. The trick is implementing a solution that will be reliable in the field
(truly not easy, believe me).

FWIW: Our code is rather abstract. Most apps are very 'dbisam' aware, and make heavy use of DBISAM native API. Our app does not. We have
an abstraction layer, and do almost nothing directly with the DBISAM api. For example, we do not ship a database with our app. Our app
dynamically creates the db at run time. At compile time, our code does not know the ultimate db structure. The db is not available at compile
time.  Etc. (There are many 'different' things about our app... but it is very very easy to distribute and support...!)


Where we are trying to go is:

a) A table fails to open
b) At this point, ideally, DBISAM tells us why (e.g. an error code that says "BLB file is missing"
 b.1) Sub ideally: We can in a high level way ask dbisam: "Should this table have a BLB ?"
c) We deal with the missing BLB


There are a few ways we can do 'c.'  

1) Strongly Preferred: A DBISAM function that recreates the BLB.
2) Next best: DBISAM func that will take any BLB file that has the right name and 'restructure it' into being the BLB for this table
3) Worst (for several reasons): We restore a BLB that was previously saved



So the questions for Tim and Y'all:

-How to do 'a' and 'b' above?
-How to do 1 or 2 above?


We are happy to pay for any time needed to help us address these issues.

Thank you!