Export records from accdb?

  • Thread starter Thread starter Tim
  • Start date Start date
T

Tim

As they say, hind sight is 20/20. Problem...

I created a database for several users. I saved the original and converted a
copy into a runtime application (accdb.) Now, a few months later, I find I
need to modify the database and add some new features. No problem, being that
I have the original. BUT... the data is in the runtime version. Is it
possible to extract the data from the runtime copy or will it have to be
re-entered?

Thanks for any help!!!

-Tim
 
Hello Tim,

I would try first to open an accdb database, then use the import function in
the External Data section. I'm don't recall what the file extention is for
a runtime database, but there is an accda type listed which might be it.

If that doesn't work, then you could open the runtime database, open the
tables and you should be able to copy and paste the records into a new
database.

God Bless,

Mark A. Sam
 
There isn't a "runtime" application as such but there is a database format
where all source code has been removed and the reports, forms, and modules
cannot be viewed in design view. This is the accde. If that is what you
have, you can create a new database and import the tables and relationships.
In the future, it is best to separate the data from the other objects to
make updating objects easier. One database should contain only tables -
this is called the "back end". The other database contains all the other
objects - this is called the "front end" with links to the tables in the
back end. That way, unless you are making schema changes to the tables, all
you need to do is to give the users a new copy of the front end and you
don't have to mess with their data at all. You can distribute the front end
as an .accdb or an .accde. When you go the .accde route, don't forget to
save your original .accdb copy in a safe place because you'll need that to
make any front end changes.
 
As the others mentioned there really is no specific changes to a accDB file
when you deploy to a runtime machine.

You can simply copy a accDB to any computer with a runtime version, or
fulltime version of access, and it will run and function.

If you need to issue a new update to your users, you can simply e-mail or
send them the file zipped up and they can place it on their desktop or
wherever and it will run with the runtime. I mention this because, often
enter some kinda misconception about the runtime system.

you can install the full version of MS access on the target computer, or the
runtime edition on the target computer. Once you've installed either
addition of MS access, any access database value copied and place on the
target computer will run (there is no special conceptual connection between
the runtime, and that particular database filed that was deployed with the
runtime).

What is significant with the runtime is much of the menu options and
importing/exporting features are not available to the end user via the
runtime edition.

So the data file itself can be mailed to you or whatever, and it's just a
regular access database file, and there are no specific changes to the
actual file itself. You can make changes to this file, and then sent it back
to the user.

What I would actually do in your case is actually send them a new front and
with your software updates and changes and modifications, and simply link it
to the existing data file that resides on their machines now (this means the
existing data file will become their back end). The only tricky part here is
you have to train or in ensure that users launch the new version of your
application, and not the old one with the data in it.

In a sense, I'm actually suggesting you split your database into two parts.
however since in your case since you already have the back end on the target
computer, you'll simply just be providing a new front end with your software
updates, but the data will remain in the old original database file. (if
you're not up to speed with split applications, then probably your best to
simply have them send the file to you for modifications, and then send it
back to them.

You should eventually adopt a split database. This allows you to issue new
updates to your software without concern overwriting their existing .

I explain the concept of a splt database here:

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
 
Thank you guys very much for your responses, they were most helpful.
I was successful at importing the data and have taken your advice to split
the database.

Thanks Again!

Tim
 
Back
Top