How do I convert a form into a data page

[pink_ladyk]

I have created a form for my data base; but would also like to "finish" the
product by converting this into a data page that my coworkers can use as
well. When I am in the form and I select save as datapage, I end up with
missing info.

 

[Jason Lopez]

I had a similar problem with a project that I was working on. You might
need to re-create the form as a Data Access Page. But, the main key is to
have a primary key on the form. Whether it is something your co-workers can
use or not doesn't really matter. The other part (and perhaps someone can
help on how to make this work) was that I could not get sub-forms to
function properly on the DAP. Inside MS Access, no problem. On the DAP,
could not get it to work.

Hope this helps give a direction to start for ya.

Jason

 

[Ken Snell \(MVP\)]

The built-in "convert to data access page" wizard often will not produce a
working DAP (data access page), especially if you have a subform on the
original form, if you're using VBA code in the form's module, etc.

DAPs use VBScript, not VBA. DAPs use ADO recordsets, not DAO ones. DAPs
cannot see most of VBA's built-in functions. DAPs cannot run macros. And so
on....

You likely will need to build the DAP from scratch, but be prepared for lots
of time and frustration because a DAP is so different from a form.

 

[David W. Fenton]

You likely will need to build the DAP from scratch, but be
prepared for lots of time and frustration because a DAP is so
different from a form.

And it's being dropped by Microsoft -- there's no future in it at
all.

 

[Ken Snell \(MVP\)]

And it's being dropped by Microsoft -- there's no future in it at
all.

For ACCESS 2007 version, yes, but many, many users are still (and likely
will continue to be) using older versions for many years to come.

Notwithstanding this, I personally eschew the use of DAPs unless a client
gives me no choice. They are a lot of work because they're so limited and
different.

 

[David W. Fenton]

For ACCESS 2007 version, yes, but many, many users are still (and
likely will continue to be) using older versions for many years to
come.

Notwithstanding this, I personally eschew the use of DAPs unless a
client gives me no choice. They are a lot of work because they're
so limited and different.

They were one of the many things MichKa declared half-baked in his
scathing article on A2K back in 1999/2000. ADPs got much better, but
DAPs were never improved, and I think the reason for that is pretty
obvious. Don't they depend on the Office Web Components?

 

[Ken Snell \(MVP\)]

They were one of the many things MichKa declared half-baked in his
scathing article on A2K back in 1999/2000. ADPs got much better, but
DAPs were never improved, and I think the reason for that is pretty
obvious. Don't they depend on the Office Web Components?

Yes, and they depend upon ADO and VBScript.

I agree; great concept theoretically, but poorly and only partially
implemented in the software.