problems when adding field properties via dao

[RichardB]

Hi:

I have some tables where I need to add or update the
DisplayControl, RowSource, etc. properties via DAO code.
The process works perfectly, but subsequent to running it
whenever I make a modification to the the table design by
hand in the table design window and attempt to save the
changes, I get an error: "Property value too large". I
cannot save further changes.

Please note, all property settings are NOT too large:
numeric values are appropriate and all string values are
less than 250 characters.

Any idea what gives?

Thanks,

Richard

 

[RichardB]

These properties most certainly do exist for Access (Jet)
fields.

If you design a table by hand, and click on the Lookup tab
for a particular field to set (for instance) the Display
Control for the field to a combo box, you are actually
creating a DisplayControl property for the field and
setting the value to the Access constant for a Combo Box
control.

I am simply doing the same thing in code:

FieldObject.Properties.Append FieldObject.CreateProperty
("DisplayControl", dbInteger, acListBox)

This works entirely properly. It is only when I try to
save subsequent changes manually that I get an error.

This is a problem in both Access 2000 and XP.

 

[RichardB]

Ah, I see as well. Just so you know, I often use lookup
controls - because, for lay users, they hide the real
values that are store in the table!

Meanwhile, this seems to be a bug of some sort - is there
any way to report it to Microsoft without paying for a
service call?

Thanks,

 

[John Spencer (MVP)]

Ah, a design philosophy dispute. IMHO users should never see the table
directly. All their access to the data should be via query-driven forms. I
think that this allows much more control over input, more flexability, etc. For
instance, my users seldom input city and state when they are entering addresses.
They enter a zipcode and I fill in a default city and state for them if the
zipcode is one listed in the tblZIPCodes table.

As far as reporting it to MS, I'm not sure if there is a free way. I do know
that if it is really a bug they will credit you/not charge you.

No promise, but if I get the time I'll try to replicate your error. If I can,
then I'll try to submit a bug report via the MVP lead. If I can't then I'll
drop you a note that I wasn't able to duplicate the problem.

 

[Stephen K. Young]

Make sure you create the property with the correct type the first time. If
you get it wrong, then the property stays there but cannot accept the proper
values. In that situation, you need to remove the property and then recreate
it.

Also create the property on the back-end table, not on a linked table.

As I recall, a DisplayControl property is dbInteger in a table field, but
may be vbInteger or something else in a form. It is confusing (tables tend
to have DAO property types, forms have VB property types, and your guess as
to whether it is a long or short integer or even boolean may be incorrect).
Your sample code looks correct, but before creating such a property I would
always look at the Type of an existing property made manually in the Access
UI first.

- Steve