From: Lars Brownies on
I'm in the pre-stage of building an application with about 15 lookup tables.
In stead of building 15 lookup forms, I'm thinking about making one generic
lookup form and changing the record source depending on the table needed. I
would have to add code for validation purposes.

Is this doable or should I make 15 separate forms?

Thanks,

Lars

From: John W. Vinson on
On Wed, 21 Apr 2010 16:20:32 +0200, "Lars Brownies" <Lars(a)Browniew.com> wrote:

>I'm in the pre-stage of building an application with about 15 lookup tables.

Just don't use lookup *FIELDS* (www.mvps.org/access/lookupfields.htm)

>In stead of building 15 lookup forms, I'm thinking about making one generic
>lookup form and changing the record source depending on the table needed. I
>would have to add code for validation purposes.
>
>Is this doable or should I make 15 separate forms?

It's certainly doable but might not be worth the hassle. One thing to consider
if you'll mainly be using these lookup tables in combo boxes on forms is to
use generic VBA code in the combo's NotInList event to give the user the
option of adding a value to the lookup table without opening a form at all.
I have a routine I developed a few years ago, but it's copyrighted by my
former employer (now out of business) so I can't post it here, but a basic
version should be pretty easy.
--

John W. Vinson [MVP]
From: Lars Brownies on
Thanks John, Milton,

I have notinlist code so that won't be a problem. I want to restrict
additions to some lookup tables to the dba controller. For instance a
category table for my reports. Maybe I'll build forms only for those kind of
tables.

Lars


"John W. Vinson" <jvinson(a)STOP_SPAM.WysardOfInfo.com> schreef in bericht
news:bt8us5pgbr0r707v73cnda5lcro3dbff64(a)4ax.com...
> On Wed, 21 Apr 2010 16:20:32 +0200, "Lars Brownies" <Lars(a)Browniew.com>
> wrote:
>
>>I'm in the pre-stage of building an application with about 15 lookup
>>tables.
>
> Just don't use lookup *FIELDS* (www.mvps.org/access/lookupfields.htm)
>
>>In stead of building 15 lookup forms, I'm thinking about making one
>>generic
>>lookup form and changing the record source depending on the table needed.
>>I
>>would have to add code for validation purposes.
>>
>>Is this doable or should I make 15 separate forms?
>
> It's certainly doable but might not be worth the hassle. One thing to
> consider
> if you'll mainly be using these lookup tables in combo boxes on forms is
> to
> use generic VBA code in the combo's NotInList event to give the user the
> option of adding a value to the lookup table without opening a form at
> all.
> I have a routine I developed a few years ago, but it's copyrighted by my
> former employer (now out of business) so I can't post it here, but a basic
> version should be pretty easy.
> --
>
> John W. Vinson [MVP]

From: InvisibleDuncan on
The code for making a generic form that you adapt depending on the
recordsource is reasonably straightforward, but I did discover a problem with
it - it won't work if you make an MDE version of your database, because MDEs
aren't able to open forms for editing.

The version I built actually only put up datasheet forms, which meant I
didn't have to muck about with field widths, etc; it simply looked at all the
fields in the table or query in question, and loaded them into the form. If
that's the kind of thing you're after, I can put the code up...
From: Lars Brownies on
In mde applications I have succesfully changed the record source during
runtime, so I'm not sure which problem you're refering to.

Could you post your code? I'd like to take a look.

Thanks,

Lars

"InvisibleDuncan" <InvisibleDuncan(a)discussions.microsoft.com> schreef in
bericht news:340F5C34-1E7A-4A28-938A-45102CC97F16(a)microsoft.com...
> The code for making a generic form that you adapt depending on the
> recordsource is reasonably straightforward, but I did discover a problem
> with
> it - it won't work if you make an MDE version of your database, because
> MDEs
> aren't able to open forms for editing.
>
> The version I built actually only put up datasheet forms, which meant I
> didn't have to muck about with field widths, etc; it simply looked at all
> the
> fields in the table or query in question, and loaded them into the form.
> If
> that's the kind of thing you're after, I can put the code up...