Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

Is there a character limitation of 200 characters per entry?

Discussion in 'Information Technology' started by SRE, Jul 28, 2006.

  1. SRE

    SRE
    Expand Collapse
    Guest

    Is there a character limitation of 200 characters per entry?
     
  2. Loading...

    Similar Threads Forum Date
    Sikh characters in famous movies Questions and Answers Jul 15, 2014
    World Milkha Singh-inspired character makes appearance on Subway Surfers Breaking News Jan 7, 2014
    The Character Pledge - To Be a Better Person ! Sikh Youth Mar 5, 2013
    General Characteristics of Satguru in Sri Guru Granth Sahib Hard Talk Jun 15, 2011
    Sikh News Playing a Sikh character was a big responsibility: Saif (Hindustan Times) Breaking News Jul 20, 2009

  3. tina

    tina
    Expand Collapse
    Guest

    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" <SRE@discussions.microsoft.com> wrote in message
    news:BEC1F863-2561-4CF3-83BC-295448F86B5D@microsoft.com...
    > Is there a character limitation of 200 characters per entry?
     
  4. John Vinson

    John Vinson
    Expand Collapse
    Guest

    On Tue, 4 Jul 2006 16:35:01 -0700, SRE <SRE@discussions.microsoft.com>
    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. SRE

    SRE
    Expand Collapse
    Guest

    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:35:01 -0700, SRE <SRE@discussions.microsoft.com>
    > 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]
    >
     
  6. Albert D.Kallal

    Albert D.Kallal
    Expand Collapse
    Guest

    >
    > 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/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


    --
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada
    pleaseNOOSpamKallal@msn.com
    http://www.members.shaw.ca/AlbertKallal
     
  7. SRE

    SRE
    Expand Collapse
    Guest

    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/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
    >
    >
    > --
    > Albert D. Kallal (Access MVP)
    > Edmonton, Alberta Canada
    > pleaseNOOSpamKallal@msn.com
    > http://www.members.shaw.ca/AlbertKallal
    >
    >
    >
     
  8. John Vinson

    John Vinson
    Expand Collapse
    Guest

    On Wed, 5 Jul 2006 00:18:01 -0700, SRE <SRE@discussions.microsoft.com>
    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]
     
  9. SRE

    SRE
    Expand Collapse
    Guest

    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 <SRE@discussions.microsoft.com>
    > 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]
    >
     
  10. John Vinson

    John Vinson
    Expand Collapse
    Guest

    On Thu, 6 Jul 2006 16:41:02 -0700, SRE <SRE@discussions.microsoft.com>
    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]
     
  11. tina

    tina
    Expand Collapse
    Guest

    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" <SRE@discussions.microsoft.com> wrote in message
    news:78565154-1599-4414-94DB-DDC509A7AADC@microsoft.com...
    > 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 <SRE@discussions.microsoft.com>
    > > 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]
    > >
     

Share This Page