Is there a character limitation of 200 characters per entry?

T

tina

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
 
J

John Vinson

Is there a character limitation of 200 characters per entry?
Click to expand...

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]
 
A

Albert D.Kallal

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.
Click to expand...

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/results.aspx?Scope=TC&Query=membership

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

John Vinson

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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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]
 
S

SRE

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
 
J

John Vinson

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.
Click to expand...

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.
Click to expand...

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?
Click to expand...

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.
Click to expand...

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]
 
T

tina

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
 
Top