By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,977 Members | 1,352 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,977 IT Pros & Developers. It's quick & easy.

copying a backend from within frontend

P: n/a
my understanding is that you can copy a backend on condition that all
recordsets are closed.
But it is not what I experience.
Is there a way to find out what keeps the backend connected? (maybe I forgot
a recordset somewhere)

thanks for any input

Michiel
Jun 27 '08 #1
Share this Question
Share on Google+
15 Replies


P: n/a
Michiel Rapati-Kekkonen wrote:
my understanding is that you can copy a backend on condition that all
recordsets are closed.
But it is not what I experience.
Is there a way to find out what keeps the backend connected? (maybe I
forgot a recordset somewhere)

thanks for any input

Michiel
You can check for the presence of the LDB file in the same directory. As
long as an LDB file exists then it is "in use".

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Jun 27 '08 #2

P: n/a
"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote:
>my understanding is that you can copy a backend on condition that all
recordsets are closed.
But it is not what I experience.
Is there a way to find out what keeps the backend connected? (maybe I forgot
a recordset somewhere)
Recordsets can include a hidden form or reports or some such. Also a database object
if you are using such.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Jun 27 '08 #3

P: n/a
"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote in message
news:Fq***************@read4.inet.fi...
my understanding is that you can copy a backend on condition that all
recordsets are closed.
But it is not what I experience.
Is there a way to find out what keeps the backend connected? (maybe I
forgot a recordset somewhere)

thanks for any input
Keep in mind that you can't call any code from a *bound* form that is
opened, that'll close all the connections.

Let me explain

form1: bound ---call forms2

form2: unbound, runs code to close form 1

You connection will stay open. Why?

it is the stack nature of objects and how ms-access cleans up it memory.

In memoory, while form1 is closed, not all of the memory is released until
the code *returns

eg:

memory form1 (and connection)
calls ----form2 (no connection
----form2 closes form1
*only* when form2 closes does the calling code + memory from form1 actually
finally get released....

So, what this means is if you manually close form1 and THEN open form2, and
then have a button on form2 that does the compact and repair, then you
should be ok. I not tried this but it possible that if form 1 called form2
via a macro (and not code), then the connection *likely* would also be
closed. It just a question when ms-access cleans up it memory...
So, if you "main" form, or startup form is un-bound, then you should be
able to place a button on that main form that does the compact and repair.
And even better way is to put a option in a custom menu bar, and have that
call code in a module. (this module code can close all forms, and since
there is no program stack called *from* that forms...there is not return
stack..and thus the connections are released).

at
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
Jun 27 '08 #4

P: n/a
How are you copying?

Using the Windows Explorer Interface one can copy and paste
"Northwinds 2007,accdb" whether or not there is a recordset open,
whether or not a lock file exists, and also, surprisingly, perhaps,
whether or not Northwinds 2007,accdb is opened exclusively. TTBOMK
this is true for all Access files, including MDB files.

If you are copying with code, then we should see the code.

On Jun 6, 2:34*pm, "Michiel Rapati-Kekkonen" <n...@nonsense.zzwrote:
my understanding is that you can copy a backend on condition that all
recordsets are closed.
But it is not what I experience.
Is there a way to find out what keeps the backend connected? (maybe I forgot
a recordset somewhere)

thanks for any input

Michiel
Jun 27 '08 #5

P: n/a
Thank you all for your splendid insights
I could combine quite a lot of it into my solution.

maybe you're also interested why I wanted it:
it is because I have to experiment with the data (a testcopy of course)
so after some experiments I need the original, fresh data again.

My startupform is unbound, but for some reason the ldb stays alive when it
is not closed.
so from the startupform I open another form, where I can close the
startupform,
then do a while-wend, checking if the ldb is still there (it takes a few
seconds),
do the copy of the data and finally open the startupform again.

I'm happy.
Thank you all

Michiel

"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote in message
news:Fq***************@read4.inet.fi...
my understanding is that you can copy a backend on condition that all
recordsets are closed.
But it is not what I experience.
Is there a way to find out what keeps the backend connected? (maybe I
forgot a recordset somewhere)

thanks for any input

Michiel
Jun 27 '08 #6

P: n/a
You may be happy, but millions of others would want a database that
worked properly. What you describe is idiocy.

On Jun 7, 8:40*am, "Michiel Rapati-Kekkonen" <n...@nonsense.zzwrote:
My startupform is unbound, but for some reason the ldb stays alive when it
is not closed.
so from the startupform I open another form, where I can close the
startupform,
then do a while-wend, checking if the ldb is still there (it takes a few
seconds),
do the copy of the data and finally open the startupform again.

I'm happy.
Jun 27 '08 #7

P: n/a
you're not always polite
"lyle fairfield" <ly************@gmail.comwrote in message
news:e9**********************************@c65g2000 hsa.googlegroups.com...
You may be happy, but millions of others would want a database that
worked properly. What you describe is idiocy.

On Jun 7, 8:40 am, "Michiel Rapati-Kekkonen" <n...@nonsense.zzwrote:
My startupform is unbound, but for some reason the ldb stays alive when it
is not closed.
so from the startupform I open another form, where I can close the
startupform,
then do a while-wend, checking if the ldb is still there (it takes a few
seconds),
do the copy of the data and finally open the startupform again.

I'm happy.
Jun 27 '08 #8

P: n/a
"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote:
>My startupform is unbound, but for some reason the ldb stays alive when it
is not closed.
Just to double check that the problem is in the startup form. What happens when you
manually close the form? Does the LDB file go away? If so then problem is in that
form. Now maybe there's a combo box or list box on that form against a table? Or
some code opening the database or a table.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Jun 27 '08 #9

P: n/a
yes, you are and were right: the combo box was unbound, but it rowsource
queried a table.
thanks

michiel

"Tony Toews [MVP]" <tt****@telusplanet.netwrote in message
news:jt********************************@4ax.com...
"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote:
>>My startupform is unbound, but for some reason the ldb stays alive when it
is not closed.

Just to double check that the problem is in the startup form. What
happens when you
manually close the form? Does the LDB file go away? If so then problem
is in that
form. Now maybe there's a combo box or list box on that form against a
table? Or
some code opening the database or a table.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Jun 27 '08 #10

P: n/a
I have a FE database and numerous BE databases (3 or 4 different clubs). The
FE database has a table listing the various clubs and the paths to the BE
databases.

I have a form where I select which Club I want to use, it removes the links
to the no longer wanted BE database and creates new links to the required
Club Db.

Might this approach be better - 1 DB for your test data, and 1 Db for your
genuine stuff.

Phil

"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote in message
news:Rk*************@read4.inet.fi...
Thank you all for your splendid insights
I could combine quite a lot of it into my solution.

maybe you're also interested why I wanted it:
it is because I have to experiment with the data (a testcopy of course)
so after some experiments I need the original, fresh data again.

My startupform is unbound, but for some reason the ldb stays alive when it
is not closed.
so from the startupform I open another form, where I can close the
startupform,
then do a while-wend, checking if the ldb is still there (it takes a few
seconds),
do the copy of the data and finally open the startupform again.

I'm happy.
Thank you all

Michiel

"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote in message
news:Fq***************@read4.inet.fi...
>my understanding is that you can copy a backend on condition that all
recordsets are closed.
But it is not what I experience.
Is there a way to find out what keeps the backend connected? (maybe I
forgot a recordset somewhere)

thanks for any input

Michiel

Jun 27 '08 #11

P: n/a
yes, but the data change by my experiments, so I need a fresh, unchanged,
set every now and then/regularly
and the genuine data are at my customer's, so that is safe.

thanks

Michiel

"Phil Stanton" <ph**@myfamilyname.co.ukwrote in message
news:me******************************@posted.plusn et...
>I have a FE database and numerous BE databases (3 or 4 different clubs).
The FE database has a table listing the various clubs and the paths to the
BE databases.

I have a form where I select which Club I want to use, it removes the
links to the no longer wanted BE database and creates new links to the
required Club Db.

Might this approach be better - 1 DB for your test data, and 1 Db for your
genuine stuff.

Phil

"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote in message
news:Rk*************@read4.inet.fi...
>Thank you all for your splendid insights
I could combine quite a lot of it into my solution.

maybe you're also interested why I wanted it:
it is because I have to experiment with the data (a testcopy of course)
so after some experiments I need the original, fresh data again.

My startupform is unbound, but for some reason the ldb stays alive when
it is not closed.
so from the startupform I open another form, where I can close the
startupform,
then do a while-wend, checking if the ldb is still there (it takes a few
seconds),
do the copy of the data and finally open the startupform again.

I'm happy.
Thank you all

Michiel

"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote in message
news:Fq***************@read4.inet.fi...
>>my understanding is that you can copy a backend on condition that all
recordsets are closed.
But it is not what I experience.
Is there a way to find out what keeps the backend connected? (maybe I
forgot a recordset somewhere)

thanks for any input

Michiel


Jun 27 '08 #12

P: n/a
Absolutely fine.

There are 2 BE Dbs. You can play about as much as you like with the Dummy
data and providing the table design and relationships in your dummy data is
identical to your genuine data, there is no problem.

Phil

"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote in message
news:Iq*************@read4.inet.fi...
yes, but the data change by my experiments, so I need a fresh, unchanged,
set every now and then/regularly
and the genuine data are at my customer's, so that is safe.

thanks

Michiel

"Phil Stanton" <ph**@myfamilyname.co.ukwrote in message
news:me******************************@posted.plusn et...
>>I have a FE database and numerous BE databases (3 or 4 different clubs).
The FE database has a table listing the various clubs and the paths to the
BE databases.

I have a form where I select which Club I want to use, it removes the
links to the no longer wanted BE database and creates new links to the
required Club Db.

Might this approach be better - 1 DB for your test data, and 1 Db for
your genuine stuff.

Phil

"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote in message
news:Rk*************@read4.inet.fi...
>>Thank you all for your splendid insights
I could combine quite a lot of it into my solution.

maybe you're also interested why I wanted it:
it is because I have to experiment with the data (a testcopy of course)
so after some experiments I need the original, fresh data again.

My startupform is unbound, but for some reason the ldb stays alive when
it is not closed.
so from the startupform I open another form, where I can close the
startupform,
then do a while-wend, checking if the ldb is still there (it takes a few
seconds),
do the copy of the data and finally open the startupform again.

I'm happy.
Thank you all

Michiel

"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote in message
news:Fq***************@read4.inet.fi...
my understanding is that you can copy a backend on condition that all
recordsets are closed.
But it is not what I experience.
Is there a way to find out what keeps the backend connected? (maybe I
forgot a recordset somewhere)

thanks for any input

Michiel




Jun 27 '08 #13

P: n/a
"Rick Brandt" <ri*********@hotmail.comwrote in
news:GY****************@nlpi067.nbdc.sbc.com:
Michiel Rapati-Kekkonen wrote:
>my understanding is that you can copy a backend on condition that
all recordsets are closed.
But it is not what I experience.
Is there a way to find out what keeps the backend connected?
(maybe I forgot a recordset somewhere)

thanks for any input

Michiel

You can check for the presence of the LDB file in the same
directory. As long as an LDB file exists then it is "in use".
Well, not necessarily. If you can't *delete* the LDB, then it's in
use (unless you lack DELETE permission on the folder where the LDB
is stored).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jun 27 '08 #14

P: n/a
"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote in
news:%L***************@read4.inet.fi:

[to Lyle:]
you're not always polite
You're seldom interesting.

I'd prefer Lyle to you.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jun 27 '08 #15

P: n/a
"Michiel Rapati-Kekkonen" <nn@nonsense.zzwrote:
>yes, you are and were right: the combo box was unbound, but it rowsource
queried a table.
thanks
You're welcome. I only know this of course because I did the same thing myself!
<smile>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Jun 27 '08 #16

This discussion thread is closed

Replies have been disabled for this discussion.