Just noticed your new post...sorry for the delay.
I noticed in your script, the tb variable you have set for your input xlsx table is set to Boring_Locations_WGS84_Attribut$, so is that one of your existing worksheets, i.e. before you defined the new range?
When you define a print area or otherwise explicitly define a range (as in a range by name in Excel 2007 described earlier), you then have that 'recognized' in ArcGIS as a new table (or 'table view', if you want to call it that) - for example, you will see that new 'table view' show up after refreshing the view in ArcCatalog (or try adding it to ArcMap). It is best to save and exit the xlsx first so no 'locking' occurs to interfere with a fresh read of the data.
EDIT: Right, I've added this statement in case it isn't clear what to do in your script. The paragraph immediately above this statement serves to demonstrate the new 'table view' and how ArcGIS recognizes it. What you need to do in the script is modify your tb pathname to point to the newly recognized table, whatever it is called in your instance.
Start with that, believe that will solve your Excel problem, but test 1st...
As for your 2nd question, the 'extra' ID I think you are referring to is the database OBJECTID (or OID) that is normal db table behavior - you don't want control of this and indeed it is not user-editable (not editable by you). Why not, you may ask? In short, this is needed to enforce internal database integrity and maintenance-type tasks....the 'database manager' needs this to do its job.
If you need your own user-defined ID you may do that as well I suppose, but I question where you are going with this. Sequential IDs sometimes fit the task if that's what you need them for and there's no other ready means to define them, but actually if all you need is a means of, say, defining uniqueness of a location (as a GPS station collection), then for most users it makes more sense to define a more 'sensible' station ID -- if you will, something like "Station 7"; it isn't necessary to have an integer field as your own unique identifier. May be getting off on a tangent here --- if you must use Access for the input table, I would think you could import it directly from Excel - not sure what difficulties exactly you are having... I have occasionally imported tables in Access directly from Excel with no worries (except for when the Excel rows are unruly). But the only reason I've ever really had to do this is when someone needs something where Access does the job better than Excel (such as the additional need for joining tables).
Hope that helps. Actually I think you best bet is to as directly as possible, convert to whatever final output format you need. Probably the single most common reason I ever maintain or copy a data table in an 'intermediate' format is when a user cannot read it from it's final converted resting place or repository. If nothing else, just remember it's generally bad practice to make multiple copies because then you may inherit the headache of redundant data you have to keep current with one another...
If I have rambled here, I strongly apologize as there is apparently not enough coffee at this late stage in the week to keep all in good short order! Further questions, let me know. Also, post back here after your testing is complete... I don't have 10.1 installed yet and would like to know how it goes. Just wondering, do you have SP 1 installed as well?
Enjoy,
Wayne
