MySql

[miker2]

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.

[Marc 'BlackJack' Rintsch]

In <11*********************@i3g2000cwc.googlegroups.c om>, 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

[miker2]

Marc 'BlackJack' Rintsch wrote:

In <11*********************@i3g2000cwc.googlegroups.c om>, 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.

[John Machin]

mi****@optusnet.com.au 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

[miker2]

John Machin wrote:

mi****@optusnet.com.au 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.

[John Machin]

[e-mail] wrote:

John Machin wrote:

mi****@optusnet.com.au 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

[Atanas Banov]

mi****@optusnet.com.au 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?

[Sibylle Koczian]

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 : Si*************@Bibliothek.Uni-Augsburg.DE

[ftc]

mi****@optusnet.com.au 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 ) )

[John Machin]

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

[Paul Boddie]

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

[miker2]

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

[Paul Boddie]

mi****@optusnet.com.au 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

[John Machin]

mi****@optusnet.com.au 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 ...