Results 1 to 11 of 11
  1. #1
    Join Date
    Jul 2003
    Location
    Australia
    Posts
    217

    Unanswered: Can't save memo fields changes

    Whenever I tried to update ANY MEMO FIELD in ONE SPECIFIC record in an SQL Server database backend, a message would always appear saying someone else is editing the same record, etc. The changes could not be saved. But in fact nobody was editing the same record.

    This happened only to one record but not others, and happened only to the memo fields in that record. It should have nothing to do with the data I tried to enter because when I tried to enter the same data into other records (the memo fields), it saved ok.

    The front-end is Access 2003. It has got to do with the Backend, not the Access front-end because this happened also when I directly edited the backend tables.

    Does anybody know what caused this problem ? Thank you in advance.
    ________
    Lepanto
    Attached Thumbnails Attached Thumbnails message.JPG  

  2. #2
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    There's no such thing as memo in SQL Server.
    Is this an mdb with linked tables?

  3. #3
    Join Date
    Jul 2003
    Location
    Australia
    Posts
    217
    Yes, linked tables. The front-end is Access 2003.

  4. #4
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Post the DDL for the table (in SQL Server). Is there a primary key defined?
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  5. #5
    Join Date
    Jul 2003
    Location
    Australia
    Posts
    217
    Hi Blindman,

    I don't think there is anything special about the table structure. The error
    happened only to the memo fields of ONE specific record.

    Yes, there is a primary key defined.

  6. #6
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Without the tools to reproduce your problem we can't do much to help really.

  7. #7
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Without the set up I can only stab in the dark, but adding a column of the ROWVERSION datatype has been useful for problems similar to this in SQL 2000 (though it was called TIMESTAMP then).

  8. #8
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Quote Originally Posted by Lepanto View Post
    I don't think there is anything special about the table structure
    I thought you wanted us to do the thinking. No details, no answer.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  9. #9
    Join Date
    Jul 2003
    Location
    Australia
    Posts
    217
    Quote Originally Posted by pootle flump View Post
    Without the set up I can only stab in the dark, but adding a column of the ROWVERSION datatype has been useful for problems similar to this in SQL 2000 (though it was called TIMESTAMP then).
    You are the man, yes, I think TIMESTAMP might be the fix I need.
    But our database got merge replication. I couldn't add a column
    to it. Would you know how to add it ?

    Thanks.

  10. #10
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    What version SQL Server?

  11. #11
    Join Date
    Jul 2003
    Location
    Australia
    Posts
    217
    Dear Pootle flump,

    Your suggestion was good - it worked, our problem was solved by adding a timestamp field.

    Thank you so much.
    ___________
    Lepanto

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •