Code to create table with increasing field numbers

[DaveA]

I've got myself into a bind here. Any help would be a life saver.
I created a form with 644 text boxes that serve as "days" for a
schedule. Each text box has a code which is populated with an X or /.

My problem is I did them all unbound. Is there a way to use code to
either create a new table or append my current table that creates the
unbound text fields starting with text0 and increasing by 1 until it
reaches 644?

Thanks in advance. I am not looking forward to creating a table with
644 text fields.
Dave

[Leigh P]

Indeed you'll find it very taxing to create 644 fields in a table - the
limit is 255.

The unbound nature of the controls on your form can be to your advantage
though - depending on the naming.
Creating a table with perhaps just a few fields and consider having the
records as the days.
You'll then just need to loop through the recordset filling in the unbound
textboxes as required.

Without knowing what your exact fields are for I can't speculate about the
specifics - but the concept will have been described plentifully before too.
(And instead of generating table fields you'll perhaps be having to rename
your form fields)

hth (a bit)
"DaveA" <ny******@yahoo.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

I've got myself into a bind here. Any help would be a life saver.
I created a form with 644 text boxes that serve as "days" for a
schedule. Each text box has a code which is populated with an X or /.

My problem is I did them all unbound. Is there a way to use code to
either create a new table or append my current table that creates the
unbound text fields starting with text0 and increasing by 1 until it
reaches 644?

Thanks in advance. I am not looking forward to creating a table with
644 text fields.
Dave

[Tom van Stiphout]

On 7 Jun 2005 17:34:48 -0700, "DaveA" <ny******@yahoo.com> wrote:

You always want to design the database before implementing the forms.
Certainly for such important functionality as you are describing.

It is good to be aware of Access' limitations before you design the
database.

Your 644 fields (if that were even possible) present a clear example
of a database design no-no: repeating groups.
Rather than a table with:
CalendarDate datetime
Period1Code text(1)
Period2Code text(1)
Period3Code text(1)
Period4Code text(1)
etc.,
better do something like:
CalendarDate datetime
Period integer
Code text(1)
A database is not a spreadsheet.

Perhaps it makes more sense to implement the schedule in Outlook: it
already implements many features found in a calendar application.

Another suggestion: hire professional help, at least for the database
design.

-Tom.

I've got myself into a bind here. Any help would be a life saver.
I created a form with 644 text boxes that serve as "days" for a
schedule. Each text box has a code which is populated with an X or /.

My problem is I did them all unbound. Is there a way to use code to
either create a new table or append my current table that creates the
unbound text fields starting with text0 and increasing by 1 until it
reaches 644?

Thanks in advance. I am not looking forward to creating a table with
644 text fields.
Dave

[(PeteCresswell)]

Per DaveA:

Thanks in advance. I am not looking forward to creating a table with
644 text fields.

My gut says there's a database design issue here.
--
PeteCresswell

[DaveA]

I checked and it's 286 fields, for some reason is skipped a lot of
numbers.

Either way it's not going to work. I will explore the spreadsheet
option.

Thanks for the info

Dave

[(PeteCresswell)]

Per DaveA:

I checked and it's 286 fields, for some reason is skipped a lot of
numbers.

Either way it's not going to work. I will explore the spreadsheet
option.

I'd bet that if you layed out the architecture here, one or more people would
explain why the DB doesn't really need 286 fields in a single table.

Having cleaned up (i.e. rewritten as DB apps) a number of projects that began
life in Excel; I get a bad feeling when somebody talks about using Excel for
what is really a DB application.
--
PeteCresswell