[sqlalchemy] Column name mapping problem in 0.3.7
Hi, I've just upgraded to 0.3.7, and when the combined table/column name is at least 30 characters I get an error from the mapper like this: sqlalchemy.exceptions.NoSuchColumnError: Could not locate column in row for column 'Column(u'EventLastCancellationDate',MSDate())' Is this a problem with the changes in 0.3.7 ? I'm using pymssql 0.8.0 with SQL server 2000. Thanks, Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: multiple M:N joins fails
I want to get recipes which belongs to a particular category and having a particular flag. So I need both joins recipe-category and recipe-flag. Michael Bayer napsal(a): On Apr 30, 2007, at 8:40 AM, ml wrote: Hi! I have 2 relations: - recipes-categories (M:N) - recipes-flags (M:N) I'd like to get something like: SELECT recipes.title FROM recipes JOIN _recipes_ctgs_recipes ON _recipes_ctgs_recipes.id_recipe = recipes.id JOIN recipes_ctgs ON _recipes_ctgs_recipes.id_recipes_ctg=recipes_ctgs.id JOIN _recipes_flgs_recipes ON _recipes_flgs_recipes.id_recipe = recipes.id JOIN recipes_flgs ON _recipes_flgs_recipes.id_recipes_flg=recipes_flgs.id WHERE recipes_ctgs.title='cat1' AND recipes_flgs.title='flag1' when I run sess.query(Recipe).join(ctgs).join(flgs).select(...) it fails with sqlalchemy.exceptions.SQLError: (ProgrammingError) table name _recipes_ctgs_recipes specified more than once where _recipes_ctgs_recipes is a secondary table. Full example attached. well, yeah, youre joining against the same relationship twice. going from ctgs to flgs makes it essentially a self referential join on recipes. i dont understand what youre trying to query for there but my intuition tells me theres probably some better way to lay out that query without 5 joins in between. if not, youll have to lay out the self referential part manually using table aliases. (note to SA old schoolers - see why i hesitated so much to add auto- joins across relationships ? every new feature spawns a whole new class of user issues) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Calling a function (Stored Procedure) returning a recordset
Hi,
I have a postgres function returning a set of records (using RETURN
NEXT). While calling the function like this:
tasklist = func.get_tasklist(engine=engine).execute() # is this the
correct way?
I am getting this error:
SQLError: ('(ProgrammingError) set-valued function called in context
that cannot accept a set\nCONTEXT: PL/pgSQL function get_tasklist
line 6 at return next\n', bound method TaskController.get_tasks of
gcollab.controllers.task.TaskController object at 0xb742716c)
'SELECT get_tasklist()' {}
Am I calling the stored procedure correctly? Need help.
thanks
Sanjay
Here is code of the stored procedure:
CREATE OR REPLACE FUNCTION get_tasklist() RETURNS setof tasklist_t AS $
$
DECLARE
t tasklist_t%rowtype;
BEGIN
FOR t IN SELECT task_id, descr, 'Waiting', remind_at, 'Sanjay'
FROM task
LOOP
RETURN NEXT t;
END LOOP;
RETURN;
END;
$$ LANGUAGE PLPGSQL;
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Column name mapping problem in 0.3.7
To add a little more info, 0.3.6 generates: SELECT [T_Event].[EventLastCancellationDate] AS [T_Event_EventLastCancell_8ab9] whereas 0.3.7 generates [T_Event].[EventLastCancellationDate] AS [T_Event_EventLastCancellationDate] From what I can find, column names can be up to 128 chars in SQL server, but maybe pymssql is truncating at 30? Graham On May 1, 8:45 am, Graham Stratton [EMAIL PROTECTED] wrote: Hi, I've just upgraded to 0.3.7, and when the combined table/column name is at least 30 characters I get an error from the mapper like this: sqlalchemy.exceptions.NoSuchColumnError: Could not locate column in row for column 'Column(u'EventLastCancellationDate',MSDate())' Is this a problem with the changes in 0.3.7 ? I'm using pymssql 0.8.0 with SQL server 2000. Thanks, Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Column name mapping problem in 0.3.7
SA is now doing no column truncation for MS-SQL, as we have not placed any limit within the MS-SQL dialects. previously, SA was truncating all identifiers to 30 characters for all dialects (including those that had much larger limitations), and it would search for these truncated names in result sets. so this seems to be something happening with the DBAPI itself. if you want to do us a favor and attempt your query with the raw DBAPI, and then look at cursor.description, we can confirm that it is truncating to 30 characters and we can place this number within the corresponding dialect so that both sides agree. if it is the case that MS-SQL overall has a 30 character restriction you might want to consider shortening your column names. On May 1, 2007, at 3:45 AM, Graham Stratton wrote: Hi, I've just upgraded to 0.3.7, and when the combined table/column name is at least 30 characters I get an error from the mapper like this: sqlalchemy.exceptions.NoSuchColumnError: Could not locate column in row for column 'Column(u'EventLastCancellationDate',MSDate())' Is this a problem with the changes in 0.3.7 ? I'm using pymssql 0.8.0 with SQL server 2000. Thanks, Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: multiple M:N joins fails
On May 1, 2007, at 4:42 AM, ml wrote: I want to get recipes which belongs to a particular category and having a particular flag. So I need both joins recipe-category and recipe- flag. ah. in that case you dont want query.join(x).join(y), you want the second join to still be relative to the original query. i think youre going to have to spell that one out explicitly for now. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Calling a function (Stored Procedure) returning a recordset
On May 1, 2007, at 7:06 AM, Sanjay wrote: Hi, I have a postgres function returning a set of records (using RETURN NEXT). While calling the function like this: tasklist = func.get_tasklist(engine=engine).execute() # is this the correct way? looks fine to me. for the rest of it, im not very familiar with PG stored procedures. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Column name mapping problem in 0.3.7
On May 1, 2007, at 7:50 AM, Graham Stratton wrote: To add a little more info, 0.3.6 generates: SELECT [T_Event].[EventLastCancellationDate] AS [T_Event_EventLastCancell_8ab9] whereas 0.3.7 generates [T_Event].[EventLastCancellationDate] AS [T_Event_EventLastCancellationDate] From what I can find, column names can be up to 128 chars in SQL server, but maybe pymssql is truncating at 30? if its the case that MS-SQL allows 128-character column names, but only 30 character label names, that would be unfortunate. i might have to rewrite the whole label-truncation code (since it cant currently differentiate between physical column names and label names). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Buildbot
Huh? I thought this was something you wantedI guess I misunderstood the thread. I don't have time to do this by myself. If someone wants to pick it up and run with it, I'll be happy to work with you and to host the buildslave here, or I'm OK with just letting the thing die, too. On 4/30/07, Michael Bayer [EMAIL PROTECTED] wrote: the main effort here is all the familiarizing and configuration of buildbots, which i have made great efforts to have no understanding of whatsoever. if a buildbot master doesnt take up a lot of ram or CPU I could run it on SA's own host. On Apr 30, 2007, at 11:43 AM, Rick Morrison wrote: Hi Mike, Pursuant to our discussion on another thread regarding buildbots, I've got a preliminary buildbot slave VM set up as follows: Ubuntu 6.10 VMware tools Python 2.4 Buildbot 0.7.4 Postgres 8.2.2 MySQL 5.0.37 Sqlite 3.3.17 (also known as version du semaine these days...) FreeTDS / UnixODBC psycopg 2.0.5.1 pysqlite 2.3.2 pyodbc 2.0.35 pymssql 0.8.0 (with some local patches to fix selectmany()) mysqldb 1.2.2 Sqlalchemy trunk If I host the bot here, it'll also be able to access a MS-SQL 2005 server. So all told, this botslave should be able to test: Postgres MySQL Sqlite MS-SQL via pyodbc (Unix) MS-SQL via pymssql (Unix) We'll still need to arrange hosting for the buildbot master (maybe someone with the PSF can help here?), and some slaves for Oracle, Firebird and Informix. Rick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Column name mapping problem in 0.3.7
s/DBAPI/DBlib/ On 5/1/07, Rick Morrison [EMAIL PROTECTED] wrote: The label-truncation code is fine. The issue isn't SA. It's the DBAPI that pymssql rides on top of...identifier limit is 30 chars, is deprecated by Microsoft, it will never be fixed. Try pyodbc, which has no such limitation. On 5/1/07, Michael Bayer [EMAIL PROTECTED] wrote: On May 1, 2007, at 7:50 AM, Graham Stratton wrote: To add a little more info, 0.3.6 generates: SELECT [T_Event].[EventLastCancellationDate] AS [T_Event_EventLastCancell_8ab9] whereas 0.3.7 generates [T_Event].[EventLastCancellationDate] AS [T_Event_EventLastCancellationDate] From what I can find, column names can be up to 128 chars in SQL server, but maybe pymssql is truncating at 30? if its the case that MS-SQL allows 128-character column names, but only 30 character label names, that would be unfortunate. i might have to rewrite the whole label-truncation code (since it cant currently differentiate between physical column names and label names). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SA support for SQLite ATTACH?
I tried the following:
import sqlalchemy as SA
md_dbA=SA.BoundMetaData('dbA')
tbl_dbAtbl=SA.Table('dbAtbl',md_dbA,autoload=True)
SA.text(ATTACH DATABASE 'C:Temp\dbB.db' as dbB_db)
tbl_dbBtbl=SA.Table('dbB_db.dbBtbl',md_dbA,schema='dbB_db',autoload=True)
===
The code fails on the line marked above. Did I mis-understand what you
said?
Also, how do I look at the echoed SQL for text function?
On Apr 30, 9:07 am, Michael Bayer [EMAIL PROTECTED] wrote:
On Apr 30, 2007, at 8:13 AM, VN wrote:
you might need to use a Table with a schema='dbA_db', just a
guess. look at the echoed sql and see if it matches things that work
at the sqlite console.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: SA support for SQLite ATTACH?
I tried the following:
import sqlalchemy as SA
md_dbA=SA.BoundMetaData('dbA')
tbl_dbAtbl=SA.Table('dbAtbl',md_dbA,autoload=True)
SA.text(ATTACH DATABASE 'C:Temp\dbB.db' as dbB_db)
tbl_dbBtbl=SA.Table('dbB_db.dbBtbl',md_dbA,schema='dbB_db',autoload=True)
===
The code fails on the line marked above. Did I mis-understand what you
said?
Also, how do I look at the echoed SQL for text function?
On Apr 30, 9:07 am, Michael Bayer [EMAIL PROTECTED] wrote:
On Apr 30, 2007, at 8:13 AM, VN wrote:
you might need to use a Table with a schema='dbA_db', just a
guess. look at the echoed sql and see if it matches things that work
at the sqlite console.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Column name mapping problem in 0.3.7
On May 1, 2007, at 11:18 AM, Rick Morrison wrote: The label-truncation code is fine. The issue isn't SA. It's the DBAPI that pymssql rides on top of...identifier limit is 30 chars, is deprecated by Microsoft, it will never be fixed. Try pyodbc, which has no such limitation. OK well, we should put the 30-char limit into pymssql's dialect. however, the way the truncation works right now, its going to chop off all the column names too...which means unless i fix that, pymssql cant be used with any columns over 30 chars in size. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Column name mapping problem in 0.3.7
The underlying DBlib limits *all* identifier names, including column names to 30 chars anyway, so no issue there. Where does the character limit go in the dialect? Can I follow Oracle as an example? On 5/1/07, Michael Bayer [EMAIL PROTECTED] wrote: On May 1, 2007, at 11:18 AM, Rick Morrison wrote: The label-truncation code is fine. The issue isn't SA. It's the DBAPI that pymssql rides on top of...identifier limit is 30 chars, is deprecated by Microsoft, it will never be fixed. Try pyodbc, which has no such limitation. OK well, we should put the 30-char limit into pymssql's dialect. however, the way the truncation works right now, its going to chop off all the column names too...which means unless i fix that, pymssql cant be used with any columns over 30 chars in size. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Buildbot
Rick Huh? I thought this was something you wantedI guess I Rick misunderstood the thread. Rick I don't have time to do this by myself. If someone wants to pick Rick it up and run with it, I'll be happy to work with you and to host Rick the buildslave here, or I'm OK with just letting the thing die, Rick too. I've got an SQLalchemy build slave running on my Mac at hom, but I've never been able to get a workable combination of auxiliary database packages. I eventually got it mostly working with PostgreSQL but there is still some fishy sqlite dependency that I can't resolve. If someone would like to help me figure things out I'd be most appreciative. Skip Montanaro --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlch. + ODBC + DBISAM... :-(
Hi, I've found SA/MSSQL is mostly stable now. I do have a few bugs outstanding, and I'm sure I'll need to dive into the source code again in the future, but it's comparably stable to the rest of SA. The unit test failures are right down, at least on Windows. I haven't tested PyODBC on other platforms; we should do that ASAP (at least as a one off exercise). I'm definitely in favor of a buildbot although I can't easily offer hardware. Anyway, I'm sure you're dying to hear the outstanding problems! Well, in my usual form of totally undecipherable notes for self, here they are: #538 - identity insert problems label subqueries in from clause - unit test proposed in #513 triggers this new unit test - len(unistr) == db.func.length(unistr) date formatting - pass as datetime objects not strings make MSNVarchar derive from Unicode #537 - scope_identity(). This always returns NULL on PyODBC ticket open on PyODBC tracker BTW, I'm a bit worried that 0.3.7 has a bug that means fetch IDs doesn't work (except with PyMSSQL), but I haven't checked this. Hopefully we'll get these little issues fixed, then from 0.3.8 SA will always ship with all unit tests passing for MSSQL. Woo! :-) Paul Rick Morrison wrote: .3.6 was stable (at least for me). One of the issues to address is going to be the multi-DBAPI support. Keeping all three stable at the same time can be tough. So starting .3.7, making pyodbc the only supported configuration is OK with me, although I'll keep pymssql up and running for the next couple of releases, as we're using it here internally. Adodbapi is starting to look like a lost cause: emails are going unanswered and there's been no updates for quite some time. Speaking of testing, Paul has done a great job at bringing MSSQL up to speed on a lot of the tests, and I believe there's only like four tests that don't pass now, and I would wager those are because of database feature issues, not overt bugs. Maybe it's time to start putting MSSQL on the regular test rotation. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Buildbot
I wouldn't think that pysqlite being installed on the master is an issue: the tests would be run on the slave and in the slave environment. I think that Skip's sqlite issue is more likely one of: a) using the included pysqlite in Python 2.5+ and issues with that or b) conflict with the sqlite library that ships with OSX and out of those, I would bet (b). The sqlite that ships for Coredata with OSX Tiger is old, and I think that SA doesn't like it. I had the same issue with an older version of FC Linux that came with a dependency on sqlite that I couldn't break. Fixed things by use ./configure with --prefix to re locate the binary. and yeah, I don't think that the masters on pybots will help, we will need our own. On 5/1/07, Michael Bayer [EMAIL PROTECTED] wrote: On May 1, 2007, at 2:49 PM, [EMAIL PROTECTED] wrote: I've got an SQLalchemy build slave running on my Mac at hom, but I've never been able to get a workable combination of auxiliary database packages. I eventually got it mostly working with PostgreSQL but there is still some fishy sqlite dependency that I can't resolve. If someone would like to help me figure things out I'd be most appreciative. Skip Montanaro but that issue is beacuse your buildbot is triggered off the Python trunk/build, which has an incompatible sqlite3 distro inside of it, or something like that, right ? i may not understand this about buildbots, but dont the buildbots on pybots.org only respond to Python checkins, as opposed to checkins on the individual projects ? or both ? is there any reason one would want to use his/her own buildmaster separate from the one on pybots.org ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlch. + ODBC + DBISAM... :-(
The 0.3.7 bug is my fault, I checked in the changes without testing on pyodbc. Didn't know that Mike would cut 0.3.7 the very next day! Guess I'll get to use that buildslave for something after all... Paul, I wasn't aware of scope_identity() not working on pyodbc, I checked it in because it was your patch and I know you work on pyodbc. It worked OK here with pymssql, so I let it go. Can you detail what the problem is with pyodbc? In the meantime, I'll make the @@IDENTITY version the default again until it's straightened out. Rick On 5/1/07, Paul Johnston [EMAIL PROTECTED] wrote: Hi, I've found SA/MSSQL is mostly stable now. I do have a few bugs outstanding, and I'm sure I'll need to dive into the source code again in the future, but it's comparably stable to the rest of SA. The unit test failures are right down, at least on Windows. I haven't tested PyODBC on other platforms; we should do that ASAP (at least as a one off exercise). I'm definitely in favor of a buildbot although I can't easily offer hardware. Anyway, I'm sure you're dying to hear the outstanding problems! Well, in my usual form of totally undecipherable notes for self, here they are: #538 - identity insert problems label subqueries in from clause - unit test proposed in #513 triggers this new unit test - len(unistr) == db.func.length(unistr) date formatting - pass as datetime objects not strings make MSNVarchar derive from Unicode #537 - scope_identity(). This always returns NULL on PyODBC ticket open on PyODBC tracker BTW, I'm a bit worried that 0.3.7 has a bug that means fetch IDs doesn't work (except with PyMSSQL), but I haven't checked this. Hopefully we'll get these little issues fixed, then from 0.3.8 SA will always ship with all unit tests passing for MSSQL. Woo! :-) Paul Rick Morrison wrote: .3.6 was stable (at least for me). One of the issues to address is going to be the multi-DBAPI support. Keeping all three stable at the same time can be tough. So starting .3.7, making pyodbc the only supported configuration is OK with me, although I'll keep pymssql up and running for the next couple of releases, as we're using it here internally. Adodbapi is starting to look like a lost cause: emails are going unanswered and there's been no updates for quite some time. Speaking of testing, Paul has done a great job at bringing MSSQL up to speed on a lot of the tests, and I believe there's only like four tests that don't pass now, and I would wager those are because of database feature issues, not overt bugs. Maybe it's time to start putting MSSQL on the regular test rotation. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlch. + ODBC + DBISAM... :-(
Good to hear that adodbapi is going to get some loving. Here's a brain dump on Unix + ODBC: There are a lot of commercial UNIX ODBC interfaces of varying quality out there; I'm not familiar with any of them. As usual with open source, there's not one but two options for free ODBC software, unixodbc (http://unixodbc.org) and iodbc (http://iodbc.org). I've used both, they both seem to work. For access to MS-SQL, they both depend on FreeTDS ( http://freetds.org) for basic TDS communcation needs (TDS=Tabular data stream: taken from Sybase). pyodbc uses an ODBC provider, both the free options above and most if not all of the commercial options should work. Here's the current options for MS-SQL access from SqlAlchemy: adodbi is Windows only, uses COM objects to communicate with MS's ADO access. pymssql is Windows/Unix (not sure about BSD/Mac), uses a very old TDS layer known as DB-lib, which you've heard me complaining about many times. I was using DB-lib to access MS-SQL from C programs back in the day. Rumour has it you've done the same, so you know DB-lib. pyodbc is Windows/Unix (again not sure about BSD/Mac), talks to an ODBC provider as outlined above. Right now, this is most likely the best supported way to access ODBC from Python. There is also the mxPython ODBC interface, does basically what pyodbc does, commercial with support. This is from the guy who wrote mxDate, which was *the* way to do dates before Python 2.3 introduced the datetime module. AFAIK, this would also depend on some ODBC provider on Unix like unixodbc/iodbc/some commercial stack. Rick On 5/1/07, Michael Bayer [EMAIL PROTECTED] wrote: On May 1, 2007, at 4:17 PM, Rick Morrison wrote: The 0.3.7 bug is my fault, I checked in the changes without testing on pyodbc. Didn't know that Mike would cut 0.3.7 the very next day! Guess I'll get to use that buildslave for something after all... Paul, I wasn't aware of scope_identity() not working on pyodbc, I checked it in because it was your patch and I know you work on pyodbc. It worked OK here with pymssql, so I let it go. Can you detail what the problem is with pyodbc? In the meantime, I'll make the @@IDENTITY version the default again until it's straightened out. Rick on a related note I was contacted by Vernon Cole who says he is taking over maintenance of adodbapi, which is a good sign to have direct access to a DBAPI maintainer. whats the current option to talk to MS-SQL via unix ? pymssql, or pyodbc with a commercial ODBC library ? (are there free unix odbc libraries ?) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: type_code/introspection the types of a ResultProxy
On May 1, 2007, at 3:02 AM, Andreas Jung wrote:
ResultProxy_instance.cursor.description returns the 7-tuple as
defined in the Python DB API containing information about the
result set.
The type_code (the second element of each tuple) is an integer:
(('id', 20, 5, 8, None, None, None), ('idgattung', 23, 2, 4, None,
None, None), ('bezeichnung', 1043, 43, 255, None, None, None),
('version', 1043, 0, 30, None, None, None), ('stand', 1114, 19, 8,
None, None, None), ('format', 1043, 3, 10, None, None, None),
('status', 23, 1, 4, None, None, None), ('umfang', 23, 1, 4, None,
None, None), ('seiten', 23, 1, 4, None, None, None), ('faxabruf',
1043, 0, 50, None, None, None), ('dateiname', 1043, 11, 255, None,
None, None), ('originalname', 1043, 30, 255, None, None, None),
('idautor', 23, 1, 4, None, None, None), ('idfassung', 23, 1, 4,
None, None, None), ('neudat', 1114, 19, 8, None, None, None),
('aedat', 1114, 19, 8, None, None, None), ('bemerkung', 25, 0, -1,
None, None, None), ('summary', 25, 74, -1, None, None, None))
AFAIK all type_codes are specific to the underlying Python DB
module. Is there a way to determine the type of a column for a
given resultset (as returned by executing a SQL statement directly)
independent of the underlying database?
The reason why I am asking: I am building a generic database
adapter for Zope 2 where I need map the types of the columns to
some Zope internal
mapping.
you can get back the SQLAlchemy types via the attribute
result.context.type_map. but those are not yet mapped to python
types (theres an ancient ticket to do so which I have never found a
way to implement which I like).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Buildbot
Rick a) using the included pysqlite in Python 2.5+ and issues with Rick that Rick b) conflict with the sqlite library that ships with OSX Rick and out of those, I would bet (b). The sqlite that ships for Rick Coredata with OSX Tiger is old, and I think that SA doesn't like Rick it. I had the same issue with an older version of FC Linux that Rick came with a dependency on sqlite that I couldn't break. Fixed Rick things by use ./configure with --prefix to re locate the binary. Yes, SA doesn't like the sqlite that ships with OSX and core Python doesn't seem to like the latest sqlite. I eventually switched to PostgreSQL but there's still something in there that SA doesn't like. Skip --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
