Results 1 to 15 of 15
  1. #1
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049

    Unanswered: Saving Changes is not permitted error.

    Hi,

    I've just made a change to a tiny table in SQL Server Management Studio (all I did was change the order of fields) and I received the attached error:

    "Saving changes is not permitted", but yet I only just successfully added a field to that same table not more than 5 minutes earlier, so saving is not an issue?!

    I figure it has to drop and re-create to shuffle field order about, so what conditions make it so that a table cannot be dropped? Is it exiting and enforced relationships?

    Any advice appreciated
    Attached Thumbnails Attached Thumbnails screenshot.jpg  
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  2. #2
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    The order of fields in a table has no meaning
    George
    Home | Blog

  3. #3
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    You're right I know, I'm a neatness freak! lol

    Still curious to know
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  4. #4
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    The concept of fields in a table has no meaning too!

    Foreign key relationships and any type of lock on the table would prevent it being dropped.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  5. #5
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Ok, so it is the relationships then... that's cool.

    Just FYI, I'm not going to bother. The field order would be nice to change; to make it neater, but I'm not going to go so far as pulling relationships apart to accomplish it ^^
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  6. #6
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Just a minor point - if you do all your object creation as scripts changes like these are trivial. If you create a load of templates for all your CRUD and object creation you get much more efficient and flexible as well as less tied in to one tool or another.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  7. #7
    Join Date
    Apr 2008
    Location
    Iasi, Romania
    Posts
    561
    Provided Answers: 2
    Quote Originally Posted by gvee
    The order of fields in a table has no meaning
    Are you sure? I think I read somewhere that in a table that has several BIT fields, it is important to keep those fields together, as their values might be stored in the same byte.
    Just a novice question.
    Florin Aparaschivei
    DB2 9.7, 10.5 on Windows
    Iasi, Romania

  8. #8
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    It is one of the properties of a relation - there is no order to the rows and no order to the columns. The rows part is well known but fewer people are aware this applies to columns too.

    What you refer to would be considered an implementation issue, however I believe that information is false. The ordinal position of columns does not correlate with the slot position on the page (the slot is the actual physical position of the data).
    Testimonial:
    pootle flump
    ur codings are working excelent.

  9. #9
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    @aflorin: nope, the order doesn't matter. But you are right about storing multiple bit fields in the same byte...
    If there are 8 or fewer bit columns in a table, the columns are stored as 1 byte. If there are from 9 to 16 bit columns, they are stored as 2 bytes, and so on.
    2000: bit (T-SQL)
    2005: bit (Transact-SQL)
    2008: bit (Transact-SQL)
    George
    Home | Blog

  10. #10
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    So this happens even if you try to change data types of a field as well?!

    This is crazy... SQL Server is nowhere near as good as I thought... I just created a CountryID field, mistakenly left it as a text field, saved the table... no problem. I immediately noticed the error, so I made my CountryID an INT and tried to save and I get this same BS.

    Very frustrating.... so what? Now I have to kick all the users out, destroy the 5 relationships to this tiny table all to just change a data type of a brand new field?

    Crazy.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  11. #11
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Indeed that is exactly what I had to do
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  12. #12
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by StarTrekker View Post
    Indeed that is exactly what I had to do
    Actually, it wasn't. Not knowing how best to do something is not the same as having to do something else. Again, if you learn how to script everything then these sort of changes are trivial.
    Code:
    ALTER TABLE myTable
    ALTER myColumn INT NOT NULL
    Quite amused that you rolled out a database to production with columns set to the wrong datatypes and it is SQL Server that is stupid....

    EDIT - my response is rather snarky. Apols - I've got a terrible hangover
    Last edited by pootle flump; 11-06-09 at 06:08.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  13. #13
    Join Date
    Jan 2004
    Location
    In a large office with bad lighting
    Posts
    1,040
    Quote Originally Posted by pootle flump View Post
    Actually, it wasn't. Not knowing how best to do something is not the same as having to do something else. Again, if you learn how to script everything then these sort of changes are trivial.
    Code:
    ALTER TABLE myTable
    ALTER myColumn INT NOT NULL
    Quite amused that you rolled out a database to production with columns set to the wrong datatypes and it is SQL Server that is stupid....

    EDIT - my response is rather snarky. Apols - I've got a terrible hangover
    Actually Poots, I think you are spot on ... It's a poor workman who blames his tools for the mistakes he makes.

    -- This is all just a Figment of my Imagination --

  14. #14
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    Quote Originally Posted by pootle flump View Post
    Just a minor point - if you do all your object creation as scripts changes like these are trivial.
    Whoah...EASY their BIG Fella...you really think so?

    If you create a load of templates for all your CRUD and object creation you get much more efficient and flexible as well as less tied in to one tool or another.
    mmmmmmm....cough...cough...the some good sheet you got there

    Carl Spackler: This is a hybrid. This is a cross, ah, of Bluegrass, Kentucky Bluegrass, Featherbed Bent, and Northern California Sensemilia. The amazing stuff about this is, that you can play 36 holes on it in the afternoon, take it home and just get stoned to the bejeezus-belt that night on this stuff.
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  15. #15
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    Quote Originally Posted by StarTrekker View Post
    So this happens even if you try to change data types of a field as well?!

    This is crazy... SQL Server is nowhere near as good as I thought... I just created a CountryID field, mistakenly left it as a text field, saved the table... no problem. I immediately noticed the error, so I made my CountryID an INT and tried to save and I get this same BS.

    Very frustrating.... so what? Now I have to kick all the users out, destroy the 5 relationships to this tiny table all to just change a data type of a brand new field?

    Crazy.

    You MIGHT want to take the advertisement out of your sig

    MOO
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

Posting Permissions

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