some problem in win32

Bug #598414 reported by s_m_l_x
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
oursql
Triaged
High
Aaron Gallagher

Bug Description

since 0.90 in windows, if i use execute() to search some data , when i fetch row i have get this exception :

Traceback (most recent call last):
  File "<pyshell#12>", line 1, in <module>
    cur.fetchone()
  File "cursor.pyx", line 185, in oursql.Cursor.fetchone (oursqlx\oursql.c:16162)
  File "statement.pyx", line 422, in oursql._Statement.fetchone (oursqlx\oursql.c:10076)
  File "statement.pyx", line 234, in oursql._Statement._bind_buffer (oursqlx\oursql.c:8024)
  File "statement.pyx", line 126, in oursql._Statement._raise_error (oursqlx\oursql.c:6997)
InterfaceError: (2036, 'Using unsupported buffer type: 3 (parameter: 3)', None)

if i use oursql0.1 these is no problem, i dont know what happen

s_m_l_x (smlx6517)
description: updated
Revision history for this message
aqua (vhx) wrote :

I have the same issue.

E:\eternity>c:\python26\python "run_server.py"
SQL Connection Established on 192.168.1.47:3306
Traceback (most recent call last):
  File "run_server.py", line 6, in <module>
    server.main()
  File "E:\eternity\server\server.py", line 994, in main
    server = ServerHandler(config, db)
  File "E:\eternity\server\server.py", line 533, in __init__
    self.db = DB_Load(self.cursor)
  File "E:\eternity\server\server.py", line 460, in __init__
    rows = cursor.fetchall()
  File "cursor.pyx", line 228, in oursql.Cursor.fetchall (oursqlx\oursql.c:16568
)
  File "statement.pyx", line 550, in oursql._Statement.fetchall (oursqlx\oursql.
c:11377)
  File "statement.pyx", line 422, in oursql._Statement.fetchone (oursqlx\oursql.
c:10076)
  File "statement.pyx", line 234, in oursql._Statement._bind_buffer (oursqlx\our
sql.c:8024)
  File "statement.pyx", line 126, in oursql._Statement._raise_error (oursqlx\our
sql.c:6997)
oursql.InterfaceError: (2036, 'Using unsupported buffer type: 1 (parameter: 3)'
, None)

Changed in oursql:
importance: Undecided → Medium
assignee: nobody → Aaron Gallagher (habnabit)
Revision history for this message
Aaron Gallagher (habnabit) wrote :

So I'm having a hell of a time reproducing this error. If I could get a minimal broken example of this, it would be fantastic.

Changed in oursql:
status: New → Incomplete
Revision history for this message
aqua (vhx) wrote :

This simple database and table cause the problem for me.
CREATE DATABASE IF NOT EXISTS `test` /*!40100 DEFAULT CHARACTER SET latin1 */;
USE `test`;
-- MySQL dump 10.13 Distrib 5.1.40, for Win32 (ia32)
--
-- Host: localhost Database: test
-- ------------------------------------------------------
-- Server version 5.1.44-community

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `item_db`
--

DROP TABLE IF EXISTS `item_db`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `item_db` (
  `id` smallint(5) NOT NULL DEFAULT '0',
  `type1` tinyint(2) unsigned NOT NULL DEFAULT '0',
  `type2` tinyint(2) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `item_db`
--

LOCK TABLES `item_db` WRITE;
/*!40000 ALTER TABLE `item_db` DISABLE KEYS */;
/*!40000 ALTER TABLE `item_db` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2010-07-25 23:25:50

Revision history for this message
Aaron Gallagher (habnabit) wrote :

There are no rows in that table. Please provide the full contents of the table, the python source used to generate the error, and the complete traceback.

Revision history for this message
aqua (vhx) wrote :

Yes there are no rows. It produces the same exact error, with or without any rows at all. It is simply a test database that produces the problem for me.

The code that produces the problem:
import oursql

host = '127.0.0.1'
port = 3303
user = 'test'
pw = 'test'
db = 'test'

db = oursql.connect(host=host, user=user, passwd=pw, db=db, port=port)

print "SQL Connection Established on %s:%s" % (host, port)

cursor = db.cursor()

cursor.execute("""SELECT * FROM `item_db`""");

rows = cursor.fetchall()

for row in rows:
            print row

Revision history for this message
aqua (vhx) wrote :

Sorry, last code is incorrect. The below code is copy-pastable to produce the error for me.

import oursql

host = '127.0.0.1'
port = 3303
user = 'test'
pw = 'test'
db = 'test'

database = oursql.connect(host=host, user=user, passwd=pw, db=db, port=port)

print "SQL Connection Established on %s:%s" % (host, port)

cursor = database.cursor()

cursor.execute("""SELECT * FROM `item_db`""");

rows = cursor.fetchall()

for row in rows:
    print row

Revision history for this message
lobe (sharpblade1) wrote :

I am having the exact same issue on windows:

>>> import oursql
>>> conn = oursql.connect(user="root",
        db="test",
        passwd="password", port=3306,host="127.0.0.1")
>>> cursor = conn.cursor()
>>> cursor.execute("SELECT * FROM `ip_addr`")
>>> cursor.fetchall()

Traceback (most recent call last):
  File "<pyshell#10>", line 1, in <module>
    cursor.fetchall()
  File "cursor.pyx", line 228, in oursql.Cursor.fetchall (oursqlx/oursql.c:16568)
  File "statement.pyx", line 550, in oursql._Statement.fetchall (oursqlx/oursql.c:11377)
  File "util.pyx", line 47, in oursql._DictWhateverMixin.fetchone (oursqlx/oursql.c:2627)
  File "statement.pyx", line 422, in oursql._Statement.fetchone (oursqlx/oursql.c:10076)
  File "statement.pyx", line 234, in oursql._Statement._bind_buffer (oursqlx/oursql.c:8024)
  File "statement.pyx", line 126, in oursql._Statement._raise_error (oursqlx/oursql.c:6997)
InterfaceError: (2036, 'Using unsupported buffer type: 3 (parameter: 3)', None)

the database is not empty - not that it should make any difference.

Revision history for this message
lobe (sharpblade1) wrote :

Also I am running a 64 bit mysql server, and using the 32 bit connector (and the 32 bit compiled oursql binaries).

Changed in oursql:
milestone: none → 1.0
importance: Medium → High
status: Incomplete → Triaged
Revision history for this message
Danny McRae (khjklujn) wrote :

I encountered this problem also, however, when I built the package from source instead of using the distributed binary, the problem went away. One big clue as to where the problem may be is that I had to edit setup.py to look for version 5.1 in the registry rather than version 5.0.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.