Code For Compact On Close?

[David W. Fenton]

Well, if by that all data would be in the back end, that poster
included a temporary MDB file stored on the client's machine as
part of the "back end," then I don't have a problem with what he
wrote. But if he meant (as I originally thought) that in a
client/server situation any temporary data would only be in the
server database, then I would still disagree with him. But you're
probably right re. what he meant.

And none of that has anything to do with the question of compacting
the "front end," regardless of which way you define it. You're
trying to change the terms of the question in order to avoid
admitting that you were wrong.

 

[Neil]

No, not really. The original point that I was making was that data needs to
be stored on the client's machine. As I said in the message you replied to,
if the person I was replying to meant that temporary data could be stored in
a temporary file on the client machine, and that temporary file on the
client machine was part of the "back end" that he was referring to, then,
yes, I was wrong, because I misunderstood his point. But if he meant that
all data in a well-designed system would be stored in the server db, then
that was the original point I was countering.

In other words, there are two distinct issues here: first the compacting
issue, and second the "all data in the back end" issue, which is what I was
countering (since I thought that meant all data in the server db). If the
person had said, "You don't need a compact because temporary data could be
placed in a temp db on the client machine," then I wouldn't have disagreed
with him. But I thought he was saying that all temp data should go in the
server db, and that was why I countered his statement.

 

[Neil]

Do you perform a Kill first, or do you just copy it over on top of it?

 

[Neil]

Well, first, I hadn't reviewed Tony's solution when I made the statement.
So, yes, you're right about that. So, with Tony's solution (and not the
fixed-temp-db solution that I was thinking of), there would be no need for
compacting.

So, to put this issue to rest, let me say once and for all: I agree with
you. OK? There is no need for compacting if you delete the temporary db and
recreate it on the fly. The only point I was making (which I thought the
person wasn't saying) was that you need temp data on the client machine,
even in a well-designed system, and you can't always use the server db for
temp data. That was the only point I was making, really.

 

[David W. Fenton]

So, to put this issue to rest, let me say once and for all: I
agree with you. OK? There is no need for compacting if you delete
the temporary db and recreate it on the fly. The only point I was
making (which I thought the person wasn't saying) was that you
need temp data on the client machine, even in a well-designed
system, and you can't always use the server db for temp data. That
was the only point I was making, really.

Well, why were you making that point? It was orthogonal to what
seems to me to be the point of discussion. Server or client has
nothing to do with it -- the main issue is whether temp data belongs
in the front end (strictly defined as the Access application).

 

[David W. Fenton]

Do you perform a Kill first, or do you just copy it over on top of
it?

In apps where I've done this, I copy over top of it in the
application close or startup. In a few cases, I've asked the user if
they want to keep their temp data between sessions. And in either
case, there's error handling in case the file is in use.

But in most of my apps, I don't do anything to it at all -- just
leave it alone, as I see no problem with letting the temp MDB bloat.

 

[David W. Fenton]

there are two distinct issues here: first the compacting
issue, and second the "all data in the back end" issue

The second one was all in your head.

 

[Neil]

OK, apparently so. Still, that's what I was discussing.

 

[Neil]

OK, one more time (with feeling...). I thought the person was saying that in
a well-designed system, all data, including temp data, would go in the
server db. I did not realize that by "back end" he was including a temp db
on the client machine. I thought by "back end" he meant strictly the server
db. So I was making the point that temp data would go on the client machine,
and not in the server db. That was the only point I was making.

The further discussions in this thread made the distinction between putting
the temp data in the application file on the client machine vs. in a temp
file on the client machine, and I don't disagree with that the temp file
approach is a superior method. But I thought he was saying that temp data
would go into the server db, and that was the point I was disagreeing with.