Is there a character limitation of 200 characters per entry?

#1 (**permalink**) 28-Jul-2006, 08:30 AM

Is there a character limitation of 200 characters per entry?
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/information-technology/12564-there-character-limitation-200-characters-per.html

*

#2 (**permalink**) 28-Jul-2006, 08:30 AM

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,
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
suggest you post to an appropriate newsgroup for the software you're using.
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564

hth

"SRE" wrote in message
news:BEC1F863-2561-4CF3-83BC-295448F86B5D@microsoft.com...
> Is there a character limitation of 200 characters per entry?

#3 (**permalink**) 28-Jul-2006, 08:30 AM

On Tue, 4 Jul 2006 16

01 -0700, SRE
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
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
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
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]

#4 (**permalink**) 28-Jul-2006, 08:30 AM

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.

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.

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.

Once again, thanks for your help. It is really appreciated.

All the Best,
SRE

"John Vinson" wrote:

> On Tue, 4 Jul 2006 16

01 -0700, SRE
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
> 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]
>

#5 (**permalink**) 28-Jul-2006, 08:30 AM

>
> 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
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
> 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
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
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
pleaseNOOSpamKallal@msn.com
http://www.members.shaw.ca/AlbertKallal

#6 (**permalink**) 28-Jul-2006, 08:30 AM

Thanks Albert!

That's really helpful.

Wishing you all the best,
SRE

"Albert D.Kallal" wrote:
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564

> >
> > 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
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
>
> 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
> pleaseNOOSpamKallal@msn.com
> http://www.members.shaw.ca/AlbertKallal
>
>
>

#7 (**permalink**) 28-Jul-2006, 08:31 AM

On Wed, 5 Jul 2006 00:18:01 -0700, SRE
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
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
>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.
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564

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]

#8 (**permalink**) 28-Jul-2006, 08:31 AM

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
> 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
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
> they're really practical in Access. FMP uses "calculated fields" in
> tables - both expressions and what I'd refer to as lookup fields;
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
> 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]
>

#9 (**permalink**) 28-Jul-2006, 08:31 AM

On Thu, 6 Jul 2006 16

02 -0700, SRE
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
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564
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.
Reference:: Sikh Philosophy Network http://www.sikhphilosophy.net/showthread.php?t=12564

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]