Deleting random access records and put byte data type in record

I do not know exactly what you mean with your second question, but the info I found here might proof useful:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconusingrandomfileaccess.asp

In second question I will like to know is there a way to for example do next:

1. open some (bmp, jpg, exe...) file for binary access read as #1 and get its contents
2. open second file for random as #1 and put content of first file in second like standard record wich can be later used properly?

OR IF THIS IS NOT POSSIBLE THEN:

Is there a way to manage records in binary file mode like in random?

The problem with your second question is that image files are not the same length, therefore you cannot access them via a recordnumber because you don't know where one record ends and the next begins as in a typical random access file.

The only way to do this would be to create your own custom header to store the byte position and length of each image in the file just as a Zip file would.

~IM

To do what you want to do with Binary information of variable size you will need to set up some large fixed Byte array to store each set of Binary information into and also store the size.  That is not a good way to do it.

It would be better if you just opened the file as Binary and stored a seek point at the beginning of each chunk of binary data (or keep the seek points in a seperate file).  Maybe store the seek point of the Previous/Next record.  For instance, create a record like this.

Public Type BLOBHeaderType
  BLOBValid As Boolean
  BLOBSeek As Long
  BLOBSize As Long
  PrevSeek As Long
  NextSeek As Long
End Type

Rather then Delete anything you can simply mark it as Invalid by BLOBValid = False.  Programitically ignore any chunk of data that has BLOBValid set to False.  If you must conserve disk space you can write a function that compacts the file getting rid of any data that has BLOBValid set to False, but that doesn't need to be done on the fly.  Only when things get too large.

Technically, you don't need a BLOBSeek point since you know that it must start a right after the record.  So you could just get the record size and advance you file pointer.  But I just threw it in if you would rather use it.  You also don't need a BLOBSize since the BLOB size is the NextSeek minus the BLOBSeek point.  But again, you might as well just store that information rather then compute it.

Now, all you do is the following.

Open the file for Binary and get the file pointer to the end of the file
You do this by walking through the file reading the headers and jumping to the NextSeek point.
It is important that you remember the last seek point so you can put it into PrevSeek of the new record.
Save the last seek point into PrevSeek after you reach the end of the file.
Save the current seek point into another variable called CurrHeaderSeek
You will need that so that you can come back and rewrite this record after you fill it up with real data.
But for now Write a dummy BLOBHeader to the file (just to make room for it).
Save the new current seek point into BLOBSeek (in your header record)
Save the size of the binary data in your BLOBSize (in your header record)
Write the Binary data to the file
Save the new current seek point into NextSeek (in your header record)
Set the BLOBValid to True (in your header record)
Seek back to the dummy BLOBHeader (that is seek back to CurrHeaderSeek)
Resave the proper BLOBHeader that we filled up nicely.

Now, what you probably want to do is add more information about each BLOB to the BLOBHeader record.  Like if this is JPG's then maybe the JPG name or some other such information that might be useful to the user.

Still, in general the above is probably the way to go.  No, actually the way to go would be to toss your BLOBs into a DB (like Access or Personal SQL Server or whatever).

You know you could also jump to the end of the file directly.  However,  you still need to know the Previous seek point.  So, you could always save a dummy record at the end of the file whose data was all junk except for the PrevSeek value.  That way, you could just jump to the end of the file and then move back the size of a record and read just that dummy record (that already has the PrevSeek value set properly).  That is probably the way I would do it since I don't like the idea of walking through the entire file (particularly if it is large).  Just more for you to consider.

In other words, add this last step to the above.

Save CurrHeaderSeek into a dummy BLOBHeader and save it to the end of the file.

And instead of reading through the entire file you would do the following.

Open the file for Binary.
Move to the end of the file minus the BLOBHeader size.
Read in the working BLOBHeader that contains the PrevSeek value already set.

Mind you you will have to handle the special case when the file is first created (empty file).  But that shouldn't be a problem.

I know that all sounds confusing, but it is really easier then what I am making it out to be.  Its just harder to explain it then to actual do it.  Maybe I'll try to explain it better if you don't understand.  Or maybe someone else wants to write you a little sample code along those lines.

It's a clever system and definitely doable.

I don't think you need BLOBSeek, or BLOBSize for that matter, since after you read that structure, the file pointer will already be sitting in the BLOB data waiting for the next read.  To read the structure, you would already have it defined, and consequently know the size.

~IM

Oh, I think that there might be a few minor pitfalls to using VB records that I should mention.  Depending on the types of data that you are storing in the record you might end up getting a bit of padding at the end of each record.  This is to say that you might end up with a byte or two extra at the end of each record (in the file itself).  That is important if you want to know the actual size of the record in the file (not in memory).  I mention this without thinking about it in any way.  It might not be a problem, it might be a problem, if I thought more about it I could tell you.  I only mention it just in case you toy with this idea and find that you are having trouble locating the next record or locating the Binary data (depending on how you get the Seek values, that is, whether you ask VB for it or whether you calculate it based on the memory sizes of the records (which is sometimes different then the actual size on disk)).  Just a thought....that I didn't have....cause I didn't think about....what you might want to think about....if you encounter such a problem..... :)

Idle_Mind:  I think that what I said above is pretty much what you were suggesting in your message.  Wish I had read your message so that it could have saved me time on typing....hee hee.

Actually, I read the question and then left my desk for a bit then came back and answered it without doing a refresh.  That'll learn me.

Hi damirsel,

Is Enlades proposal something you want to pursue?  I don't think anyone will move forth with coding it without a nod from you since it is conceptually easy buy not necessarily trivial to code.

~IM