Is there a character limitation of 200 characters per entry?

per entry to what? a table? a text field in a table? are you using MS
Access? if so, more details, please, on what you're trying to do. if not,
suggest you post to an appropriate newsgroup for the software you're using.

hth


"SRE" <(E-Mail Removed)> wrote in message
news:BEC1F863-2561-4CF3-83BC-(E-Mail Removed)...
> Is there a character limitation of 200 characters per entry?

On Tue, 4 Jul 2006 16:35:01 -0700, SRE <(E-Mail Removed)>
wrote:

>Is there a character limitation of 200 characters per entry?

2048 characters *actually used* in a record, across all fields. This
does not include Memo fields, which can contain up to two gigabytes in
a single record (if you don't mind having that one record take up your
entire database).

Could you explain what you're trying to accomplish? Perhaps letting us
know your version of Access would help too.

John W. Vinson[MVP]

>
> One of the main things I need to learn is how to keep records of new and
> renewing members each year. At the moment, records for individuals are
> written over with new date data each time a member renews. We really need
> a
> record of when people renewed their membership each year. Does this kind
> of
> function exist in Access? If so, can you please let me know the name of
> that
> function and whether it is easy to set up? Please let me know if I need
> to
> describe this query better.

There is not a particular function or feature that does what you want.
However, ms-access is most certainly capable of keeping a history of past
renewal information. It is much like question:

I have a hammer, will you please show me how the hammer can build a
house.

Well, a hammer is most certainly used in building a house, but you have to
have a house design BEFORE you start using the hammer.

So, building a house, or a office table is not a particular "feature" of a
hammer, but a hammer can most certainly build both.

So, what you need is to sit down, and consider what historic information you
want to keep. The key to making ms-access (or a hammer) work is to have a
understating of the task at hand, and then learn how to "model" your data.
In ms-access, we use the concept of data modeling to "solve" your types of
problems (likely, you would consider a history table that is RELATED to the
main contact/customer table).

A sample template for memberships can be found at Microsoft's site

http://office.microsoft.com/en-us/re...ery=membership

In addition, a design for people involved in multiple memberships can be
found here:
http://www.databaseanswers.org/data_...ents/index.htm


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)
http://www.members.shaw.ca/AlbertKallal

Thanks Albert!

That's really helpful.

Wishing you all the best,
SRE

"Albert D.Kallal" wrote:

> >
> > One of the main things I need to learn is how to keep records of new and
> > renewing members each year. At the moment, records for individuals are
> > written over with new date data each time a member renews. We really need
> > a
> > record of when people renewed their membership each year. Does this kind
> > of
> > function exist in Access? If so, can you please let me know the name of
> > that
> > function and whether it is easy to set up? Please let me know if I need
> > to
> > describe this query better.
>
> There is not a particular function or feature that does what you want.
> However, ms-access is most certainly capable of keeping a history of past
> renewal information. It is much like question:
>
> I have a hammer, will you please show me how the hammer can build a
> house.
>
> Well, a hammer is most certainly used in building a house, but you have to
> have a house design BEFORE you start using the hammer.
>
> So, building a house, or a office table is not a particular "feature" of a
> hammer, but a hammer can most certainly build both.
>
> So, what you need is to sit down, and consider what historic information you
> want to keep. The key to making ms-access (or a hammer) work is to have a
> understating of the task at hand, and then learn how to "model" your data.
> In ms-access, we use the concept of data modeling to "solve" your types of
> problems (likely, you would consider a history table that is RELATED to the
> main contact/customer table).
>
> A sample template for memberships can be found at Microsoft's site
>
> http://office.microsoft.com/en-us/re...ery=membership
>
> In addition, a design for people involved in multiple memberships can be
> found here:
> http://www.databaseanswers.org/data_...ents/index.htm
>
>
> --
> Albert D. Kallal (Access MVP)
> Edmonton, Alberta Canada
> (E-Mail Removed)
> http://www.members.shaw.ca/AlbertKallal
>
>
>

On Wed, 5 Jul 2006 00:18:01 -0700, SRE <(E-Mail Removed)>
wrote:

>Hi John and Tina,
>
>Thanks Very Much for your replies.
>
>I'm thinking of transfering a FileMakerPro membership database which I have
>running for the organisation over to the Microsoft Access 2003 which I also
>have on my computer.

In my experience, FMP databases need a fair bit of redesign before
they're really practical in Access. FMP uses "calculated fields" in
tables - both expressions and what I'd refer to as lookup fields;
these are features which in Access are better reserved for Queries,
rather than trying to put them directly into tables.

>The reason I chose Access is because advanced face-to-face training is more
>available in this program.
>
>I have 36 fields so far, and the maximum amount of characters in one of
>these fields is probably about 100. So, it seems that John has answered my
>question and that Access will serve the purpose well.

36 x 100 = 3600, above the limit. Be careful: this limit is a bit
nasty, since you can create a table with 36 100-byte fields with no
errors, warnings, or problems. It's only when a user actually FILLS
such a record that they'll get a (possibly confusing) error message.

>One of the main things I need to learn is how to keep records of new and
>renewing members each year. At the moment, records for individuals are
>written over with new date data each time a member renews. We really need a
>record of when people renewed their membership each year. Does this kind of
>function exist in Access? If so, can you please let me know the name of that
>function and whether it is easy to set up? Please let me know if I need to
>describe this query better.

See Albert's suggested reading. Overwriting the member's data would
NOT be either necessary nor desirable. You'ld want (at least) two
tables: a table of Members, and a separate linked table of Renewals.

I think you'll find Access to be powerful and effective - just don't
assume that it works just like FileMaker, because it doesn't!!

John W. Vinson[MVP]

Hi John,

Thanks for that info.

I suppose I should be clearer about what we really want Access to do.

Our FMP database is not doing what it's meant to, because it lost features
when it was moved onto a new computer, so there's no loss there. I've
already imported the data into an Access table without any difficulty.

In FMP or Access, at the moment it is not possible to extract data on new
and renewed members for each past year, but we would really like to be able
to do this in the new database.

If it's not good practice to overwrite data each time a member renews, does
that mean I would have to re-enter the membership details each time a member
renews?

If so, the database would just keep getting bigger and bigger as I would
need to keep using the old data to search whether the member is a new or
renewing member.

I hope I'm being clearer about the basic question now.

Thanks Very Much for you help with this.

SRE


"John Vinson" wrote:

> On Wed, 5 Jul 2006 00:18:01 -0700, SRE <(E-Mail Removed)>
> wrote:
>
> >Hi John and Tina,
> >
> >Thanks Very Much for your replies.
> >
> >I'm thinking of transfering a FileMakerPro membership database which I have
> >running for the organisation over to the Microsoft Access 2003 which I also
> >have on my computer.
>
> In my experience, FMP databases need a fair bit of redesign before
> they're really practical in Access. FMP uses "calculated fields" in
> tables - both expressions and what I'd refer to as lookup fields;
> these are features which in Access are better reserved for Queries,
> rather than trying to put them directly into tables.
>
> >The reason I chose Access is because advanced face-to-face training is more
> >available in this program.
> >
> >I have 36 fields so far, and the maximum amount of characters in one of
> >these fields is probably about 100. So, it seems that John has answered my
> >question and that Access will serve the purpose well.
>
> 36 x 100 = 3600, above the limit. Be careful: this limit is a bit
> nasty, since you can create a table with 36 100-byte fields with no
> errors, warnings, or problems. It's only when a user actually FILLS
> such a record that they'll get a (possibly confusing) error message.
>
> >One of the main things I need to learn is how to keep records of new and
> >renewing members each year. At the moment, records for individuals are
> >written over with new date data each time a member renews. We really need a
> >record of when people renewed their membership each year. Does this kind of
> >function exist in Access? If so, can you please let me know the name of that
> >function and whether it is easy to set up? Please let me know if I need to
> >describe this query better.
>
> See Albert's suggested reading. Overwriting the member's data would
> NOT be either necessary nor desirable. You'ld want (at least) two
> tables: a table of Members, and a separate linked table of Renewals.
>
> I think you'll find Access to be powerful and effective - just don't
> assume that it works just like FileMaker, because it doesn't!!
>
> John W. Vinson[MVP]
>

On Thu, 6 Jul 2006 16:41:02 -0700, SRE <(E-Mail Removed)>
wrote:

>Hi John,
>
>Thanks for that info.
>
>I suppose I should be clearer about what we really want Access to do.
>
>Our FMP database is not doing what it's meant to, because it lost features
>when it was moved onto a new computer, so there's no loss there. I've
>already imported the data into an Access table without any difficulty.

The data is one thing. The Access application is a different one.

>In FMP or Access, at the moment it is not possible to extract data on new
>and renewed members for each past year, but we would really like to be able
>to do this in the new database.

Access should be able to handle this perfectly well.

>If it's not good practice to overwrite data each time a member renews, does
>that mean I would have to re-enter the membership details each time a member
>renews?

No, it does not. Please reread my message. In Access - UNLIKE FMP -
you would store this information in *two separate tables* within the
Access database. You would store the membership details, once only, in
a Members table; this table would have one record for each member.

The renewal data would be stored in a *separate* table, with a
MemberID field as a link to Members but containing *NO* member
biographical information; each renewal would have a new record. For
example you might have a Membership record like

Members

MemberID 239
LastName Jones
FirstName Kevin
Address 123 Main St
City ...

Renewals

RenewalID 8132
MemberID 239
RenewalDate 7/11/2005
Payment $25

RenewalID 9446
MemberID 239
RenewalDate 7/1/2006
Payment $28

This would typically be edited and displayed using a Form based on
Members, with a Subform based on Renewals.

>If so, the database would just keep getting bigger and bigger as I would
>need to keep using the old data to search whether the member is a new or
>renewing member.

Bigger and bigger. Note that 10,000,000 rows of renewals for 1,000,000
members is starting to get "biggish" for Access.

John W. Vinson[MVP]

you can dump all kinds of data into an Access table; that doesn't mean it's
properly normalized or related. recommend you study relational design
principles, before you jump into this with both feet. since you're making
the move from another software program because you want to get more out of
your data, you should make every effort to get the most out of Access and
the incredible power it offers - when you use the tool correctly, that is.
suggest you take a look at http://home.att.net/~california.db/tips.html,
which offers my standard recommendations to Access newbies; focus first on
Tip 1 and Tip 2.

hth


"SRE" <(E-Mail Removed)> wrote in message
news:78565154-1599-4414-94DB-(E-Mail Removed)...
> Hi John,
>
> Thanks for that info.
>
> I suppose I should be clearer about what we really want Access to do.
>
> Our FMP database is not doing what it's meant to, because it lost features
> when it was moved onto a new computer, so there's no loss there. I've
> already imported the data into an Access table without any difficulty.
>
> In FMP or Access, at the moment it is not possible to extract data on new
> and renewed members for each past year, but we would really like to be
able
> to do this in the new database.
>
> If it's not good practice to overwrite data each time a member renews,
does
> that mean I would have to re-enter the membership details each time a
member
> renews?
>
> If so, the database would just keep getting bigger and bigger as I would
> need to keep using the old data to search whether the member is a new or
> renewing member.
>
> I hope I'm being clearer about the basic question now.
>
> Thanks Very Much for you help with this.
>
> SRE
>
>
> "John Vinson" wrote:
>
> > On Wed, 5 Jul 2006 00:18:01 -0700, SRE <(E-Mail Removed)>
> > wrote:
> >
> > >Hi John and Tina,
> > >
> > >Thanks Very Much for your replies.
> > >
> > >I'm thinking of transfering a FileMakerPro membership database which I
have
> > >running for the organisation over to the Microsoft Access 2003 which I
also
> > >have on my computer.
> >
> > In my experience, FMP databases need a fair bit of redesign before
> > they're really practical in Access. FMP uses "calculated fields" in
> > tables - both expressions and what I'd refer to as lookup fields;
> > these are features which in Access are better reserved for Queries,
> > rather than trying to put them directly into tables.
> >
> > >The reason I chose Access is because advanced face-to-face training is
more
> > >available in this program.
> > >
> > >I have 36 fields so far, and the maximum amount of characters in one of
> > >these fields is probably about 100. So, it seems that John has
answered my
> > >question and that Access will serve the purpose well.
> >
> > 36 x 100 = 3600, above the limit. Be careful: this limit is a bit
> > nasty, since you can create a table with 36 100-byte fields with no
> > errors, warnings, or problems. It's only when a user actually FILLS
> > such a record that they'll get a (possibly confusing) error message.
> >
> > >One of the main things I need to learn is how to keep records of new
and
> > >renewing members each year. At the moment, records for individuals are
> > >written over with new date data each time a member renews. We really
need a
> > >record of when people renewed their membership each year. Does this
kind of
> > >function exist in Access? If so, can you please let me know the name
of that
> > >function and whether it is easy to set up? Please let me know if I
need to
> > >describe this query better.
> >
> > See Albert's suggested reading. Overwriting the member's data would
> > NOT be either necessary nor desirable. You'ld want (at least) two
> > tables: a table of Members, and a separate linked table of Renewals.
> >
> > I think you'll find Access to be powerful and effective - just don't
> > assume that it works just like FileMaker, because it doesn't!!
> >
> > John W. Vinson[MVP]
> >