Hello!

We are chasing the issue described in these threads:

http://www.elevatesoft.com/scripts/newsgrp.dll?action=searchopenmsg&group=5&msg=59824&keywords=BLB

http://www.elevatesoft.com/scripts/newsgrp.dll?action=searchopenmsg&group=5&msg=60161&keywords=blb*%20missing*#msg60161

http://www.elevatesoft.com/scripts/newsgrp.dll?action=searchopenmsg&group=5&msg=59845&keywords=blb*%20deleted*#msg59845



What we are trying to do is to add to the DBRepair functionality to allow it to recreate
any missing blb files. Right now, the DBRepair blows up when it touches a table that has a
missing blb.

How should we achieve this?

Thanks!!!

Assuming that the missing .blb files are from EMPTY tables, it's probably
safe to delete the remnants (.idx, .dat) and call a the CreateTables
(reverse-engineered table creation unit) to create the missing table.  Since
the script includes code like: "if (not Exists)", you should be ok for
calling it as a blanket, to re-create any missing tables (once you've
eliminated the remnants).

No .... that won't work.

I have a table, with data.

In essentially all cases, there is zero data in the blb column.

But the blb itself is gone (see threads referred to above).

So the table won't open, and the DBISAM DB Repair feature gags.


I need to be able to fix the table (e.g. to recreate the blb and make everything happy again.

How Best To Do This?


a) Is there some extended functionality in DBISAM itself I can use ?
b) Is there some other path I can take?


Thanks!!!

"Sam Jones" <rafael@zfirmllc.com> wrote in message
news:9E8BD38C-A361-4E9C-8EEF-
> I have a table, with data.
> In essentially all cases, there is zero data in the blb column.

Then your case is definitely more complicated...

Does anyone know if AOL/CA are doing anything to address this?

"Sam Jones" <rafael@zfirmllc.com> wrote in message
news:9E8BD38C-A361-4E9C-8EEF-78F5D3FE81B2@news.elevatesoft.com...
> b) Is there some other path I can take?
>

If you are willing to do it in code, then keep a copy of the empy blob
(different name) in the folder where you have the database, and copy it to
mytable.blb if mytable.blb is missing. Very DOS, but I can't think of a good
solution.

Robert

>
> Thanks!!!
>

"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in message
news:276C3FA8-A767-44E8-9289-
> If you are willing to do it in code, then keep a copy of the empy blob
> (different name) in the folder where you have the database, and copy it to
> mytable.blb if mytable.blb is missing. Very DOS, but I can't think of a
> good solution.
If that works, then he could also this:
If .BLB is missing, create sub-dir "fixme", maybe in privatedir. Call
createtable to make a new table in that dir.
Now copy the .BLB into the real directory, to marry with good .idx, .dat.
Delete "fixme" directory.
This way, you don't have to have spare empty .BLB files sitting around,
which could/would get deleted by the rogue anti-spyware anyway.

"Chris Thornton" <chris@thornsoft.com> wrote in message
news:9BF465DA-2898-4981-BE75-C455CD104208@news.elevatesoft.com...
> "Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in message This way,
> you don't have to have spare empty .BLB files sitting around, which
> could/would get deleted by the rogue anti-spyware anyway.
>

One would hope that he would NOT name the empty blob files "blb", right? and
doing a simple if not fileexists('something.blb') then
copyfile('something.bbb', 'something.blb') is much simpler than your method.

Robert

"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in message
news:B8DF237F-1741-454E-A29C-
> One would hope that he would NOT name the empty blob files "blb", right?
> and
Yes, I suppose an extension of ".dontdeletemeplease" would be better. Do we
know that the anti-spyware looks at the extension? Maybe it's looking at the
contents, in which case, it would be deleted no matter what. You'd have to
obfuscate it somehow, maybe zipping or UPXing.

> doing a simple if not fileexists('something.blb') then
> copyfile('something.bbb', 'something.blb') is much simpler than your
> method.

It depends on your distribution. Your method involves adding .bbb files to
your setup. If you also distribute on portable/U3 platforms, you've got
those packages to deal with as well. I use DBISAM because it has NO
distribution hassles. I don't ship .IDX, .DAT, or .BLB files.  So in my
case, shipping empty .BBB files would indeed, be more risky (modifying a
setup, .U3P and .PAF that don't have any reason to know anything about
DBISAM files right now) than a few lines of Delphi code.

"Chris Thornton" <chris@thornsoft.com> wrote in message
news:487F1826-21A3-46B2-8E23-ECC8C4C2A1D6@news.elevatesoft.com...
> distribution hassles. I don't ship .IDX, .DAT, or .BLB files.  So in my
> case, shipping empty .BBB files would indeed, be more risky (modifying a

At some point, you create the database files. So at that point, you copy the
BLB files into BBB. One line of code per file. No rocket science there.

Point is, we're dealing with a very unorthodox situation. Hopefully, it will
get resolved. If it does not, then DBISAM developers will have to change to
another extension.

Robert

"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in message
news:0F79E3F0-D6A5-4ADC-98A3-
> At some point, you create the database files. So at that point, you copy
> the BLB files into BBB. One line of code per file.
Sure, if you're talking about a brand new install.
But if  you've got existing data, and you want to design the next version of
the program to deal with the missing .BLB files, you can't just copy the
..BLB files over to .BBB.

>No rocket science there.
Agreed. But your approach assumes you're still on the launch pad and can
change the mission before blast-off, and my approach can fix problems when
you're already in space....