stringobject.c:4491: bad argument to internal function

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Connection is successful, shows target system: "Microsoft SQL Server
2000 - 8.00.2040(Intel X86) Enterprise Edition on Windows NT 5.2 (Build
3790:Service Pack 2).
2. In the navigator I can browse the tables and I see the individual
columns of each table.
3. Try to submit a simple query
select TOP 50 *
from mydbname

What is the expected output? What do you see instead?
After submitting:
"Query failed (0.000 secons)
../Objects/stringobject.c:4491: bad argument to internal function"

What version of the product are you using? On what operating system? Python
version?
Ubuntu 8.10, crunchyfrog 0.3.3 from ppa repo

Please provide any additional information below.

Original issue reported on code.google.com by 4chanarc...@gmail.com on 10 Feb 2009 at 10:32

[GoogleCodeExporter]

Issue 47 has been merged into this issue.

Original comment by albrecht.andi on 18 Mar 2009 at 8:14

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I am having the same issue, as is a friend of mine.  Using CrunchyFrog 0.4.1 
from ppa
repo on Kubuntu 9.10 (32-bit) with Python 2.6.4

Database type is SQL Server and Data Source -> Edit -> Test Connection works 
fine.
Connection gets established normally.

Executing any query produces the exact error as follows:
- Query Failed (0.000 seconds)
- ../Objects/stringobject.c:4640: bad argument to internal function

Original comment by dunnomat...@gmail.com on 14 Dec 2009 at 9:59

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Does this happen with every query or do some queries work?

Original comment by albrecht.andi on 15 Dec 2009 at 5:26

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I had some issues using pymssql from the repos (currently 1.0.1 in Karmic) - 
though I
forget the exact errors.

I updated to the latest version of the module (1.0,2) and it's been fine - 
might be
worth trying that :) (fwiw, I use virtualenv to easily bottle up python 
dependencies)

Original comment by darren.w...@gmail.com on 15 Dec 2009 at 11:38

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Albrecht - thanks for checking on this...it happens for any query, including 
each of
the following ('applicant' is a table):
select * from applicant;
select getdate();
SELECT SYSDATETIME();

Darren - I suspected it was something in like that in a dependent Python Python
module.  I'll see if I can find a version to pull.  Thanks for the tip, I'll 
let you
guys know what I see.

Original comment by dunnomat...@gmail.com on 15 Dec 2009 at 2:43

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Thanks for investigating! I can't recall it, but I think I've seen a posting on 
some 
mailing list about a similar issue and it was related to the pymssql module. 
Today I've 
contacted the author of pymssql because the first item in the release notes for 
pymssql 
1.0.2 looks much like this issue. I'll let you know when I've got a reply.

Original comment by albrecht.andi on 15 Dec 2009 at 2:46

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Andi,

That was it.  The problem resolved after installing pymssql 1.0.2.  Thank you 
(and
thanks Darren).  Of the many SQL clients I've ever used, crunchyfrog is my 
favorite
by far...one client for Oracle/MySQL/SQL Server is so convenient.  Like many 
others,
I appreciate all of your effort.  I have a few other questions for you that 
I'll take
offline.

-Matt

Original comment by dunnomat...@gmail.com on 15 Dec 2009 at 5:08

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Thanks :)

I've just received feedback from the author of pymssql and it looks like this 
is fixed 
in pymssql 1.0.2.

Original comment by albrecht.andi on 15 Dec 2009 at 6:54

• Changed state: Invalid
• Added labels: ****
• Removed labels: ****