MS Access - Compact and Repair ??

.
I am not as familiar with Access as I am VBA/Excel and VB.

I have a database project constructed in VB6. It stores records in an Access table/sheet.

#1 - Is it necessary that this arrangement require a periodic Compact/Repair process since Access is only storing the data ?

#2 - I have read different websites that talk about Compact/Repair when the database program is closed and other sites that speak to C/R as the last thing BEFORE the database program closes.
Which process is better and why ?

#3 - For some reason (maybe my VBA / VB experiience) I an leaning toward the C/R as a 'before closed' process of the database. Will this produce future errors ?

The project uses Microsoft ActiveX Data Objects.

Thank you for your assistance !

.
Thank you for your response.

Sounds like it won't be much of a problem 'cuz the project is a stand alone, desktop version. Used by one person mainly for input and periodic review without editing.
I don't forsee the database being larger than 100,000 - 200,000 records.

Don't know if you've gone very far on this, but C/R is always a good idea. As pointed out by dflak, when you "churn" your data in Access, you create records but do not actually delete obsolete records. This is because of the way Access uses dynamic memory. In essence, you really can only do one of two things to a record - thread it into the table structure or unthread it. Append (Insert) and Update create records - either new for Append or updated copies for Update. Then they thread the new copy into the list and remove the old copy at the same time. But the way this is one, the removed record creates a "gap" in memory so that, when a lot of churning occurs, a memory map of what is actually in use will start to look like a Swiss cheese. What the C/R does is it rebuilds the lists of records for each table by copying them in a way that fully occupies memory with no gaps. I.e. squeezes the holes out of the cheese.

As to performance, it is rarely an issue EXCEPT that if you had a really large DB and started to do some churning, you would find that the system was working harder to find places to put things. A C/R does this: It makes the file physically smaller. If you also have disk compression turned on as a weekly thing, then making your file smaller and contiguous gives you a better chance to find records quickly because the compressed files require fewer system "extent pointers" which means less processing. Are you likely to actually SEE this performance boost? Not on modern computers, since any spinning disk still requires head movement that will be measured in milliseconds but 1 msec is typically over a million instructions. The difference in processing an extra extent pointer is pretty much lost in the shuffle.

.
Thank you Doc-Man for your insight.