Can you convert (just tables in) a 2010 accdb back to 2003 mdb?

If you have committed no evil, then you can create a new mdb file and export all your tables back to it.
Evil being attachment fields and multi-value fields--evils you shouldn't have used anyway

You mean if the ACCDB has other objects also ?

I don't think so.  But, why not just import your tables in to a blank ACCDB,  then convert that back to A2003 ?

mx

Just to clarify ... what I meant by "I don't think so." was that you can save just the tables separately.

mx

Nay, my heart is pure, and I have committed no evil! Huzzah!  :-D

I just couldn't find the "Save As 2003". Silly me - I looked in the Database Tools where it used to freakin' be!  I should have known they'd put it somewhere you'd NEVER think to look, like "Save & Publish"!

I just love Access 2010! This pictures are so pretty, and the colors are so shiny!

I can deal with Access 2010
The Ribbon is ...well...saner than in 2007 and BackStage is reasonable to work with.
Once you have a look at what's in BackStage, you do tend to remember it.
Where they stuffed Compact & Repair in A2007 was maddening.
I rolled back from A2007 and firmly resolved to never touch it again.
Every day, day to day stuff is still A2003 though.

Word to the wise: DON'T create forms or reports in A2010 and then try to edit them in A2003
They become corrupted very quickly.
If you have created them in 2010, you may as well copy-and-paste everything to new A2003 objects.
Because they die

I have just spent the last 2 hours working with an app that was converted from 97 to 2003, then to 2010, was reported to have been working, then all of a sudden, "nothing works"

I got into it, and saw that all the VBA was gone (form, report, module)

Somebody I work with here says one of her 2010 converted app's lost the code, but kept the Function & Sub declaration lines!

We had a similar isolated occurrence some time ago (in Access 2007).  In our case, it happened when a developer lost patience with the time it was taking to digitally sign the code, and killed the database through Task Manager.  The code was completely lost.  Fortunately we had backups... and we learned to just wait out the signing process.

I personally have a lot of paranoia going on.
Everything lives on drives with shadow copies enabled.
I have a Dev folder where I work on stuff
I have a Prod folder where a copy of the production stuff lives
I have a Deploy folder where the vbscript files that pull production frontends down to each machine where it lives after I rev them.
And then the front end lives on every machine.

Between all the Previous Copies on all the HDD's in the outfit, I got it covered.

And then there's server backups.

Sounds a bit like our environment...

Development + testing + staging + production = plenty of backups when things go wrong

I got sick of kicking out everybody when I wanted to push out changes, and while I saw Tony Toews' FE updater, I wanted to roll my own.
So I wrote two VBScripts.
One knocks forward a number in a file called ver.txt and copies the Dev version to the Deploy folder.
On the front end, another script has a look for
1) is there a file name *Backup.mdb?
    Yup, somebody crashed their front-end, let's deep-six it and clean up, and pull something new down from Deploy
2) is the ver.txt on the local unit got a smaller rev number than the one in Deploy?
    Yup, let's pull down the changes

Then it opens the app.  Or it just opens the same-version app when no changes have been pushed.

One double-click to deploy is a happy thing.
Not EVER having to clean up crashed front-ends is also VERY nice.
"You crashed it? No problem.  Just say yes to all the prompts, and then close and re-open it again"

A nice side effect is there are multiple good prodcution copies around.

And yes <when things go wrong > is the right description.
Having heavily tweaked forms and reports go brittle is a fact of life.
Having a working file to import an object from--which then immediately gets rebuilt--is an absolute necessity