"PROPERTY VALUE IS TOO LARGE" MESSAGE – Error 3309

Topic

New Reply

“PROPERTY VALUE IS TOO LARGE” MESSAGE – Error 3309

Using Access 2000 (9.0.4402) SR-1

The *.dbf table tblBPermit is originally imported into a temporary database BuildCvt where it is reworked with proper field names, AutoNumber, key,, etc. then with the following macro TransferDatabase definition:

Export, Microsoft Access, Build_BE.mdb, Table, tblBPermit, tblBPermit, No

it is exported to production database Build_BE.mdb

When I open Build_BE.mdb tblBPermit in Design View, make change to Description field, and save I get “Property Value is too Large” message.

When I go back and open BuildCvt.mdb tblBPermit in Design View, make change to Description field or add additional fields, and save, it saves OK

Name AutoCorrect is not checked
Subdatasheet Name is set to None

The table has 168 fields. This table structure was converted from Access 97 to Access 2000. Never had problems saving it with Access 97.

How can I tell which property value it is complaining about?

Is there a limit on table size?

How can I tell what a table object size is?

Any ideas?

John Graves

Reply | Quote

Replies

[indent]

---

When I open Build_BE.mdb tblBPermit in Design View, make change to Description field, and save I get “Property Value is too Large” message.

---

[/indent]What size do you have the field set for? Is “Description” the name of the field? (If so, I’d suggest you modify it, since Description is also a property name in Access.) Or are you talking about the field description, which is what it sounds like from the message, since that is a property of the field?

You aren’t running into a limitation on table size unless your database is approaching 2 Gb size, but you may be hitting a RECORD length limit, depending on the field sizes you have used.

Reply | Quote

Hi Charlotte

When I open Build_BE.mdb tblBPermit in Design View, make change (just press the space bar) in Description field (property), and save I get “Property Value is too Large” message.

When I go back and open BuildCvt.mdb tblBPermit in Design View, make change to Description field or add additional fields, and save, it saves OK

John Graves

Reply | Quote

What happens if you IMPORT the table that works into the Build_BE database? Does it still work? If so, then something is putting a kink in it in your transferdatabase operation. If that’s the case, the next step might be to convert your macro to code and see if there’s any difference if you run it using code. I’ve rarely used TransferDatabase, but I haven’t had problems with it when I did.

Reply | Quote

Interesting

I Imported tblBPermit as you suggested, at just about completion of building indexes, received “The operation failed. There are too many indexes on table tblBPermit OK” message

I had to click OK 5 times to clear dialog box.

There are 8 legitimate indexes in the source tblBPermit table, after viewing destination tblBPermit table Indexes, it revealed 32 indexes (the max). It automatically created an index for any non-indexed field that has ID or Code in the field name.

Is there a way to turn off this feature? DUH, yes there is!

Tools, Options, Tables/Queries, AutoIndex on Import/Create (I cleared this)

This (index creation) was happening on 42 other tables.

Needless to say my performance is better, and my database when from 53 MB to 39 MB

After all this, including Detect & Repair, I get the same “PROPERTY VALUE IS TOO LARGE” MESSAGE – Error 3309 as described above.

I did notice when I get “Property Value is too Large OK” message. I Click OK

I get “Errors encountered during the save operation OK” message. I Click OK, exit Design View again, say No to Save Change message, go back into design view and my changes are there.

What next?

PS: I attached tbpBPermit for your review.

Reply | Quote

Well, at least you cured a problem you didn’t know you had! So now you’re getting the same message on the table you imported, a message that you didn’t get in the other database?

OK, I looked at the table. Sorry, but this isn’t a relational table, it’s a flat table with far too much stuff in it. In addition to around 180 fields, you have 34 combobox lookups on it. The combobox lookups are probably the real reason for all those indexes it created, and they’re one of the reasons your database is bloated, since they create temporary queries themselves and that pushes up the size of the database. It’s a general rule of thumb that users don’t see tables, they see forms and reports and possibly queries, so there isn’t any good reason to put lookups on tables like that, and it is probably part of your problems with the table.

I get the same error message, which appears to be the result of table corruption. If I create a new table in design view and then copy the fields from the design view of the existing table and paste them into the design view of the new table, it allows changes to the descriptions. However, I can’t append records directly from the corrupted table. What I had to do was export the records in the table to a Word Mail Merge format, which is tab delimited text. Then I imported the text file back into Access and was able to append the records. You’ll have to watch out for one of the fields where you have a pound sign in the field name, because it gets replaced by an underscore when you import the table back in.

Reply | Quote

Hi Charlotte

Sorry you had to see that table. It is a transition table from a legacy to access database. Was able to drop 10 fields. It then exports OK, and can be maintained/saved in its new location.

Thanks for your help.

John Graves

Reply | Quote