MySql

Discussion in 'Python' started by miker2@optusnet.com.au, Jul 27, 2006.

  1. Guest

    HI,

    I'm having trouble writing to a MySql db using python and the MySQLdb
    module. Here is the code:

    import MySQLdb
    base = MySQLdb.connect(host="localhost", user="blah", passwd="blah",
    db="test_py")
    cursor = base.cursor()
    cursor.execute("INSERT INTO table (field) VALUES (int)")

    this does not work but the interesting thing is, there is an
    AUTO_INCREMENT
    field. Now say i had a couple of entries in there already:
    auto table
    1 | 90
    2 | 32

    and then i run my py script 3 times, the data is not entered but if i
    add
    another entry from mysql the auto increment field will have counted the

    python entries:
    auto table
    1 | 90
    2 | 32
    6 | 47

    please tell me what i am doing wrong. thanks.
     
    , Jul 27, 2006
    #1
    1. Advertising

  2. In <>, miker2 wrote:

    > import MySQLdb
    > base = MySQLdb.connect(host="localhost", user="blah", passwd="blah",
    > db="test_py")
    > cursor = base.cursor()
    > cursor.execute("INSERT INTO table (field) VALUES (int)")
    >
    > this does not work but the interesting thing is, there is an
    > AUTO_INCREMENT
    > field. Now say i had a couple of entries in there already:
    > auto table
    > 1 | 90
    > 2 | 32
    >
    > and then i run my py script 3 times, the data is not entered but if i
    > add
    > another entry from mysql the auto increment field will have counted the
    >
    > python entries:
    > auto table
    > 1 | 90
    > 2 | 32
    > 6 | 47
    >
    > please tell me what i am doing wrong. thanks.


    Where's the problem? Do you mind that the third entry has a 6 as unique
    `auto` value? Doesn't `AUTO_INCREMENT` just guarantee unique values?

    Ciao,
    Marc 'BlackJack' Rintsch
     
    Marc 'BlackJack' Rintsch, Jul 27, 2006
    #2
    1. Advertising

  3. Guest

    Marc 'BlackJack' Rintsch wrote:
    > In <>, miker2 wrote:
    >
    > > import MySQLdb
    > > base = MySQLdb.connect(host="localhost", user="blah", passwd="blah",
    > > db="test_py")
    > > cursor = base.cursor()
    > > cursor.execute("INSERT INTO table (field) VALUES (int)")
    > >
    > > this does not work but the interesting thing is, there is an
    > > AUTO_INCREMENT
    > > field. Now say i had a couple of entries in there already:
    > > auto table
    > > 1 | 90
    > > 2 | 32
    > >
    > > and then i run my py script 3 times, the data is not entered but if i
    > > add
    > > another entry from mysql the auto increment field will have counted the
    > >
    > > python entries:
    > > auto table
    > > 1 | 90
    > > 2 | 32
    > > 6 | 47
    > >
    > > please tell me what i am doing wrong. thanks.

    >
    > Where's the problem? Do you mind that the third entry has a 6 as unique
    > `auto` value? Doesn't `AUTO_INCREMENT` just guarantee unique values?
    >
    > Ciao,
    > Marc 'BlackJack' Rintsch


    the problem is that the entry from python: cursor.execute("INSERT INTO
    table (field) VALUES (3)") is not there.

    the auto increment counts the entries 1,2,3,4,5, ect. the 3,4,5 in
    the example above is where i've run the py script and as you can see
    there are not there. the 6 is an entry from mysql.

    so basically the data from python is not being entered but the auto
    increment is being counted. thanks.

    sorry about the dodgie description.
     
    , Jul 27, 2006
    #3
  4. John Machin Guest

    wrote:
    > HI,
    >
    > I'm having trouble writing to a MySql db using python and the MySQLdb
    > module. Here is the code:
    >
    > import MySQLdb
    > base = MySQLdb.connect(host="localhost", user="blah", passwd="blah",
    > db="test_py")
    > cursor = base.cursor()
    > cursor.execute("INSERT INTO table (field) VALUES (int)")


    I've never used MySQL but they're all much the same --
    "table" is a reserved word. What is "int" supposed to be? That's not
    valid SQL AFAIK. Is that exactly what you typed? Or are you coyly
    obfuscating?

    Try this:
    cursor.execute("INSERT INTO tablename (fieldname) VALUES (42)")
    or better,
    somevar = 42
    cursor.execute("INSERT INTO tablename (fieldname) VALUES (?)",
    (somevar,))
    even better, read the docs and look at the examples :)


    >
    > this does not work


    .... and the error message was ... what? If it's not a state secret, how
    about divulging it?


    > but the interesting thing is, there is an
    > AUTO_INCREMENT
    > field. Now say i had a couple of entries in there already:
    > auto table
    > 1 | 90
    > 2 | 32
    >
    > and then i run my py script 3 times, the data is not entered but if i
    > add
    > another entry from mysql the auto increment field will have counted the
    >
    > python entries:
    > auto table
    > 1 | 90
    > 2 | 32
    > 6 | 47


    Evidently it's committed the auto increment before it decides that it
    doesn't like your SQL or whatever. Read the warranty card that came
    with the autoincrementer gizmoid; you won't find "continuous" or "no
    gaps" mentioned anywhere.

    > please tell me what i am doing wrong.


    Inter alia, not giving enough clear unambiguous info about what your
    problem really is.

    Cheers,
    John
     
    John Machin, Jul 27, 2006
    #4
  5. Guest

    John Machin wrote:
    > wrote:
    > > HI,
    > >
    > > I'm having trouble writing to a MySql db using python and the MySQLdb
    > > module. Here is the code:
    > >
    > > import MySQLdb
    > > base = MySQLdb.connect(host="localhost", user="blah", passwd="blah",
    > > db="test_py")
    > > cursor = base.cursor()
    > > cursor.execute("INSERT INTO table (field) VALUES (int)")

    >
    > I've never used MySQL but they're all much the same --
    > "table" is a reserved word. What is "int" supposed to be? That's not
    > valid SQL AFAIK. Is that exactly what you typed? Or are you coyly
    > obfuscating?
    >
    > Try this:
    > cursor.execute("INSERT INTO tablename (fieldname) VALUES (42)")
    > or better,
    > somevar = 42
    > cursor.execute("INSERT INTO tablename (fieldname) VALUES (?)",
    > (somevar,))
    > even better, read the docs and look at the examples :)
    >
    >
    > >
    > > this does not work

    >
    > ... and the error message was ... what? If it's not a state secret, how
    > about divulging it?
    >
    >
    > > but the interesting thing is, there is an
    > > AUTO_INCREMENT
    > > field. Now say i had a couple of entries in there already:
    > > auto table
    > > 1 | 90
    > > 2 | 32
    > >
    > > and then i run my py script 3 times, the data is not entered but if i
    > > add
    > > another entry from mysql the auto increment field will have counted the
    > >
    > > python entries:
    > > auto table
    > > 1 | 90
    > > 2 | 32
    > > 6 | 47

    >
    > Evidently it's committed the auto increment before it decides that it
    > doesn't like your SQL or whatever. Read the warranty card that came
    > with the autoincrementer gizmoid; you won't find "continuous" or "no
    > gaps" mentioned anywhere.
    >
    > > please tell me what i am doing wrong.

    >
    > Inter alia, not giving enough clear unambiguous info about what your
    > problem really is.
    >
    > Cheers,
    > John



    sorry guys...

    forget about the auto incrementer for a second.

    the entry is not being recorded. that is my problem. the script does
    not work. thanks.
     
    , Jul 27, 2006
    #5
  6. John Machin Guest

    wrote:
    > John Machin wrote:
    > > wrote:
    > > > HI,
    > > >
    > > > I'm having trouble writing to a MySql db using python and the MySQLdb
    > > > module. Here is the code:
    > > >
    > > > import MySQLdb
    > > > base = MySQLdb.connect(host="localhost", user="blah", passwd="blah",
    > > > db="test_py")
    > > > cursor = base.cursor()
    > > > cursor.execute("INSERT INTO table (field) VALUES (int)")

    > >
    > > I've never used MySQL but they're all much the same --
    > > "table" is a reserved word. What is "int" supposed to be? That's not
    > > valid SQL AFAIK. Is that exactly what you typed? Or are you coyly
    > > obfuscating?
    > >
    > > Try this:
    > > cursor.execute("INSERT INTO tablename (fieldname) VALUES (42)")
    > > or better,
    > > somevar = 42
    > > cursor.execute("INSERT INTO tablename (fieldname) VALUES (?)",
    > > (somevar,))
    > > even better, read the docs and look at the examples :)
    > >
    > >
    > > >
    > > > this does not work

    > >
    > > ... and the error message was ... what? If it's not a state secret, how
    > > about divulging it?
    > >
    > >
    > > > but the interesting thing is, there is an
    > > > AUTO_INCREMENT
    > > > field. Now say i had a couple of entries in there already:
    > > > auto table
    > > > 1 | 90
    > > > 2 | 32
    > > >
    > > > and then i run my py script 3 times, the data is not entered but if i
    > > > add
    > > > another entry from mysql the auto increment field will have counted the
    > > >
    > > > python entries:
    > > > auto table
    > > > 1 | 90
    > > > 2 | 32
    > > > 6 | 47

    > >
    > > Evidently it's committed the auto increment before it decides that it
    > > doesn't like your SQL or whatever. Read the warranty card that came
    > > with the autoincrementer gizmoid; you won't find "continuous" or "no
    > > gaps" mentioned anywhere.
    > >
    > > > please tell me what i am doing wrong.

    > >
    > > Inter alia, not giving enough clear unambiguous info about what your
    > > problem really is.
    > >
    > > Cheers,
    > > John

    >
    >
    > sorry guys...
    >
    > forget about the auto incrementer for a second.
    >
    > the entry is not being recorded. that is my problem. the script does
    > not work. thanks.


    OK we've forgotten about the auto incrementer.

    Now tell us what "does not work" means.
    Show us an actual suitably-cut down script that "does not work".
    If you get an error message, tell us what the error message was.
    If you didn't get an error message, bloody well tell us that you
    didn't.

    BTW, if the script doesn't contain

    base.commit()

    somewhere, take yourself out to the back lane and give yourself a good
    thumping :)
    Then come back in and read the docs about transactions and commit and
    autocommit etc.

    HTH,
    John
     
    John Machin, Jul 27, 2006
    #6
  7. Atanas Banov Guest

    wrote:

    > sorry guys...
    >
    > forget about the auto incrementer for a second.
    >
    > the entry is not being recorded. that is my problem. the script does
    > not work. thanks.


    after Dijkstra: "the use of mySql cripples the mind; its teaching
    should, therefore, be regarded as a criminal offence. "

    thus said, which mysql engine are you using for your DB? is it
    transactional, should you commit?
     
    Atanas Banov, Jul 27, 2006
    #7
  8. On 26 Jul 2006 23:39:45 -0700, declaimed the
    following in comp.lang.python:

    >
    > please tell me what i am doing wrong. thanks.


    Uhm... Did you COMMIT the inserts? auto-increment has to operate
    when the insert statement is run, but without the commit, those inserted
    records are rolled-out; but the increments can not be rolled out as some
    other client may have inserted between your insert and potential commit.

    --
    Wulfraed Dennis Lee Bieber KD6MOG

    HTTP://wlfraed.home.netcom.com/
    (Bestiaria Support Staff: )
    HTTP://www.bestiaria.com/
     
    Dennis Lee Bieber, Jul 27, 2006
    #8
  9. John Machin schrieb:
    >
    > BTW, if the script doesn't contain
    >
    > base.commit()
    >
    > somewhere, take yourself out to the back lane and give yourself a good
    > thumping :)


    That's not really fair, because transactions were added to MySQL only a
    short time ago (at least to the default table type). There simply hasn't
    yet been time for every experienced MySQL user to get hit by the need to
    commit things.

    --
    Dr. Sibylle Koczian
    Universitaetsbibliothek, Abt. Naturwiss.
    D-86135 Augsburg
    e-mail : -Augsburg.DE
     
    Sibylle Koczian, Jul 27, 2006
    #9
  10. ftc Guest

    a écrit :
    > import MySQLdb
    > base = MySQLdb.connect(host="localhost", user="blah", passwd="blah",
    > db="test_py")
    > cursor = base.cursor()
    > cursor.execute("INSERT INTO table (field) VALUES (int)")
    >
    > this does not work but the interesting thing is, there is an
    > AUTO_INCREMENT
    > field. Now say i had a couple of entries in there already:
    > auto table
    > 1 | 90
    > 2 | 32
    >
    > and then i run my py script 3 times, the data is not entered but if i
    > add
    > another entry from mysql the auto increment field will have counted the
    >
    > python entries:
    > auto table
    > 1 | 90
    > 2 | 32
    > 6 | 47
    >
    > please tell me what i am doing wrong. thanks.



    The dbapi2 specification says:
    "if the database supports an auto-commit feature, this must be initially
    off"

    So you have to do a commit ( base.commit() ) or to enable auto-commit at
    the beginning ( base.autocommit( True ) )
     
    ftc, Jul 27, 2006
    #10
  11. John Machin Guest

    Sibylle Koczian wrote:
    > John Machin schrieb:
    > >
    > > BTW, if the script doesn't contain
    > >
    > > base.commit()
    > >
    > > somewhere, take yourself out to the back lane and give yourself a good
    > > thumping :)

    >
    > That's not really fair, because transactions were added to MySQL only a
    > short time ago (at least to the default table type). There simply hasn't
    > yet been time for every experienced MySQL user to get hit by the need to
    > commit things.
    >


    As I said earlier, I don't use MySQL. I wasn't aware it didn't have
    transactions -- what did people use it for, then? So is the upshot is
    that he should thump himself for using a DBMS w/o transactions,
    perhaps?

    Cheers,
    John
     
    John Machin, Jul 27, 2006
    #11
  12. Paul Boddie Guest

    John Machin wrote:
    > Sibylle Koczian wrote:
    > > John Machin schrieb:
    > > >
    > > > base.commit()


    [...]

    > > That's not really fair, because transactions were added to MySQL only a
    > > short time ago (at least to the default table type). There simply hasn't
    > > yet been time for every experienced MySQL user to get hit by the need to
    > > commit things.


    This is mentioned in the MySQLdb FAQ:

    http://sourceforge.net/docman/display_doc.php?docid=32070&group_id=22307

    The default behaviour has been changed to match the DB-API standard,
    which probably matches the normal behaviour on most mainstream
    relational database systems.

    > As I said earlier, I don't use MySQL. I wasn't aware it didn't have
    > transactions -- what did people use it for, then? So is the upshot is
    > that he should thump himself for using a DBMS w/o transactions,
    > perhaps?


    Some awareness of common practice would certainly be beneficial.
    Attempting to insert data into PostgreSQL, Oracle, sqlite and so on
    would produce similar results to those described. The principal
    difference is that with MySQL (and presumably with things like
    Microsoft Access' storage engine that no-one takes seriously anyway),
    everyone has been able to get away with ignoring transactions and
    considering such behaviour as normal (or not even considering that
    anyone really uses anything which does anything else), and this
    obviously affects software governed by such assumptions.

    I suppose it's unfortunate for anyone who was using MySQLdb prior to
    release 1.2.0, especially if the software didn't give any obvious
    run-time warnings (not that I can say whether it did or not), but the
    MySQL-centric culture of ignoring/ridiculing stuff they don't support
    (and then eventually supporting it, in this case) is probably most to
    blame if we have to point the finger.

    Paul
     
    Paul Boddie, Jul 27, 2006
    #12
  13. Guest

    Paul Boddie wrote:
    > John Machin wrote:
    > > Sibylle Koczian wrote:
    > > > John Machin schrieb:
    > > > >
    > > > > base.commit()

    >
    > [...]
    >
    > > > That's not really fair, because transactions were added to MySQL only a
    > > > short time ago (at least to the default table type). There simply hasn't
    > > > yet been time for every experienced MySQL user to get hit by the need to
    > > > commit things.

    >
    > This is mentioned in the MySQLdb FAQ:
    >
    > http://sourceforge.net/docman/display_doc.php?docid=32070&group_id=22307
    >
    > The default behaviour has been changed to match the DB-API standard,
    > which probably matches the normal behaviour on most mainstream
    > relational database systems.
    >
    > > As I said earlier, I don't use MySQL. I wasn't aware it didn't have
    > > transactions -- what did people use it for, then? So is the upshot is
    > > that he should thump himself for using a DBMS w/o transactions,
    > > perhaps?

    >
    > Some awareness of common practice would certainly be beneficial.
    > Attempting to insert data into PostgreSQL, Oracle, sqlite and so on
    > would produce similar results to those described. The principal
    > difference is that with MySQL (and presumably with things like
    > Microsoft Access' storage engine that no-one takes seriously anyway),
    > everyone has been able to get away with ignoring transactions and
    > considering such behaviour as normal (or not even considering that
    > anyone really uses anything which does anything else), and this
    > obviously affects software governed by such assumptions.
    >
    > I suppose it's unfortunate for anyone who was using MySQLdb prior to
    > release 1.2.0, especially if the software didn't give any obvious
    > run-time warnings (not that I can say whether it did or not), but the
    > MySQL-centric culture of ignoring/ridiculing stuff they don't support
    > (and then eventually supporting it, in this case) is probably most to
    > blame if we have to point the finger.
    >
    > Paul


    Thanks for the thumping, will try harder next time.
    _________________________________________________

    Thanks for commit comment i think that whats i need.
    _________________________________________________

    I think you should support people rather than pay them out despite
    thier Ignorance.
     
    , Jul 27, 2006
    #13
  14. Paul Boddie Guest

    wrote:
    > Paul Boddie wrote:
    > > the MySQL-centric culture of ignoring/ridiculing stuff they don't support
    > > (and then eventually supporting it, in this case) is probably most to
    > > blame if we have to point the finger.


    [...]

    > I think you should support people rather than pay them out despite
    > thier Ignorance.


    For the record, I was mostly referring to MySQL AB in my finger
    pointing above - there's a long history of them encouraging fashionably
    non-standard thinking, ostensibly because of some radical insight into
    why everyone else is supposedly doing the wrong thing, but in reality
    due to some shortcomings in their product which they're not willing to
    admit (at least until they've put them right).

    Anyway, I think most of us are happy to help people out who are
    suddenly discovering new depths to technologies they thought they
    already knew.

    Paul
     
    Paul Boddie, Jul 27, 2006
    #14
  15. John Machin Guest

    wrote:

    >
    > Thanks for the thumping, will try harder next time.
    > _________________________________________________
    >
    > Thanks for commit comment i think that whats i need.
    > _________________________________________________
    >
    > I think you should support people rather than pay them out despite
    > thier Ignorance.


    There are (at least) 3 possible responses to people who have not read
    the docs and/or who say their code "doesn't work" without providing
    any/enough details:

    (1) No response: Ignore them, and hope evolution works -- that ain't
    support
    (2) Spoon-feed them -- that's support of the "life-support machine"
    type
    (3) Attempt to tell them how to lift their game ...
     
    John Machin, Jul 28, 2006
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. JL
    Replies:
    0
    Views:
    1,178
  2. Ravi
    Replies:
    6
    Views:
    1,443
    Suchandra Thapa
    Jul 21, 2003
  3. Replies:
    2
    Views:
    6,249
  4. washakie
    Replies:
    4
    Views:
    955
    washakie
    Jan 15, 2008
  5. Jeffrey H. Coffield
    Replies:
    1
    Views:
    1,933
Loading...

Share This Page