A few more thoughts:
(1) Is your database perhaps open in exclusive mode? (If it is open in
shared mode, there will be an .ldb file of the same name in the same folder
with your mdb; in exclusive mode, there is no .ldb file.) In exclusive
mode, I would not expect other use of the same connection to be permitted.
(2) Sorry to be so dense, but I still don't have a very good picture of what
you're trying to accomplish.
It sounds as if you are importing a variety of tables, with a variety of
table structures.
However, each table has address and map information.
I don't think you're going to be able to display maps (some sort of graphic,
presumably) in datasheet view.
Unless you have some way of identifying the name of the field containing the
graphic, you'll have a hard time displaying this field on a generic form,
either.
Until you mentioned the maps, I had this in mind:
Having selected a table name into a variable MyTable,
DoCmd.OpenTable "MyTable"
DoCmd.Maximize
If you're already working in maximized mode, the second line won't be
necessary.
Your table should display, taking up the entire screen.
The user can work in it, then close it when he's finished, returning to your
screen.
Of course a sophisticated user can get into mischief with this design, but I
don't see how it would be confusing for the beginning user you describe.
If you have a set of tables which won't change, you could create a separate
form for each one, then display the appropriate one in a single subform
control on your form, by changing the subform control's ControlSource
property.
But if you expect to be importing more forms, with as yet undefined table
structures, this won't help, either.
Or at least it won't solve the entire problem.
Switching between datasheet and single form view is not too difficult, I
think, using DoCmd.RunCommand acCmdDataSheetView and DoCmd.RunCommand
acCmdFormView.
(3) I'm not sure I follow your logic in rejecting VB, or selecting Access,
but I do hope that the above is of some use to you.
I might be able to advise you better if I had a clearer understanding of
where your tables are coming from and what use you want to make of their
data.
HTH
- Turtle
"Aladdin Nassar" <anassar@yahoo.com> wrote in message
news:4027dad8$0$202$75868355@news.frii.net...[color=blue]
> Thank you for your reply, MacDermott. Let me answer your questions to
> clarify:
>
> (1) I am using Access 2002 & 2003. I tried using
> CurrentProjeect.Connection to the same mdb file I am developing in. It
> refused connection saying the file was locked.
>
> (2) I need to show the table's contents on the same form. Each record
> has an address, and as the user traverses the table, they get to see the
> map associated with that address, make any edits if necessary and
> save/cancel before moving to the next record. Ideally, I would like to
> use a subform that I can switch between single and mulitple record view
> (Single vs. Dataseheet), but the problem is that the form assumes I know
> the table's structure apriori. Opening multiple modal/non-modal forms
> would confuse my users, unless you tell me how to make them look like
> one form.
>
> (3) The reason why I decided to use MS Access' runtime for development
> instead pure VB in the first place, is the import/export functionality
> that allows the users to import/export tables. That is why I import
> tables into the local (same) mdb file. I don't need any system tables,
> and even if I did, I can easily hide it from the user. That way the
> user can still use the power of MS Access plus the added functionality
> of mapping addresses no matter where they are stored.
>
> I would really appreciate if you can direct me to the easiest way to
> either get a subform to open any table in DataSheet format irrespective
> of its schema, or any other way that allows read/write data-binding to
> the underlying table, given the above information.
>
> Aladdin Nassar
>
>
>
> *** Sent via Developersdex
http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it![/color]
