On Mon, Jun 8, 2009 at 2:46 PM, ddorothy wrote:
>
> I have looked into this and considered what you have said. I think I
> have come up with a potential solution. It seems to be that the most
> common driver for mssql on non-windows platforms is going to be
> freeTDS. Since there appears to be
I vigorously agree.
pjjH
On Jun 8, 8:57 pm, Michael Trier wrote:
> On Mon, Jun 8, 2009 at 5:29 PM, Michael Bayer wrote:
>
>
>
> > I'd rather a flag, or better yet in 0.6 a freetds specific dialect/url,
> > i.e. mssql+freetds://.
>
> I personally like the freetds dialect idea because there's a
On Mon, Jun 8, 2009 at 5:29 PM, Michael Bayer wrote:
>
>
> I'd rather a flag, or better yet in 0.6 a freetds specific dialect/url,
> i.e. mssql+freetds://.
>
I personally like the freetds dialect idea because there's a lot more issues
specific to freetds than just this one.
--
Michael Trier
ht
I'd rather a flag, or better yet in 0.6 a freetds specific dialect/url,
i.e. mssql+freetds://.
ddorothy wrote:
>
> I have looked into this and considered what you have said. I think I
> have come up with a potential solution. It seems to be that the most
> common driver for mssql on non-window
I have looked into this and considered what you have said. I think I
have come up with a potential solution. It seems to be that the most
common driver for mssql on non-windows platforms is going to be
freeTDS. Since there appears to be no way of knowing what ODBC is
using under the hood we sho
I love that we're putting this level of thought into the issue. I
also hate that the state of MSSQL requires us to put this level of
thought into the issue.that said, carry on !
On May 9, 2009, at 4:21 PM, Rick Morrison wrote:
> There are some differences on what happens then the MS Wi
There are some differences on what happens then the MS Windows ODBC driver
connects to an MSSQL database, and what happens when FreeTDS connects, and I
believe that the three most common problems reported for pyodbc on FreeTDS:
1) string encoding issues (attempting to execute unicode statements
> If you change the test case to indicate that supports_unicode and
> supports_unicode_statements = False, then it runs just fine with the
> fix. Without the fix it fails as well, which indicates to me the
> issue is in FreeTDS.
>
> I'd like to commit this but I want to have a discussion with Mik
On May 6, 7:56 am, Ed Singleton wrote:
> If it helps, I have finally got my system working, now using FreeTDS
> 0.82, SQLAlchemy 0.5.3, pymssql, Python 2.5, (all on Mac Leopard) and
> SQL Server 2005 (on an WinXP vm).
>
> With this setup, your test passes without any problems.
>
> I also tri
If it helps, I have finally got my system working, now using FreeTDS
0.82, SQLAlchemy 0.5.3, pymssql, Python 2.5, (all on Mac Leopard) and
SQL Server 2005 (on an WinXP vm).
With this setup, your test passes without any problems.
I also tried it out using pyodbc 2.1.5 and the test failed with
Mike ... thanks for picking this up! Just so you know, I haven't done
any other testing of my change to see how it interacts with, say, db
triggers that fire on the insert.
I can add an another small bit of info: I also see the dialect unit
test failures (test_fetchid_trigger and test_slice_mssq
On 27 Apr, 16:01, Tom Wood wrote:
> Hi all,
>
> Am having a problem withSQLAlchemy0.5.3 and MSSQL. Running on a
> Debian stack, using FreeTDS 0.82, pyodbc 2.1.4, Python 2.5 and
> (separately) SQL Server 2000 and SQL Server 2005.
I have a fairly comparable setup, with SQLALchemy 0.5.3, Python 2.
On Apr 30, 11:04 pm, mtrier wrote:
> > Some additional info, and a possible fix:
>
> > ===
> > --- lib/sqlalchemy/databases/mssql.py (revision 5930)
> > +++ lib/sqlalchemy/databases/mssql.py (working copy)
> > @@ -991,7 +991,7 @
On Apr 29, 10:08 am, Tom Wood wrote:
> Some additional info, and a possible fix:
>
> ===
> --- lib/sqlalchemy/databases/mssql.py (revision 5930)
> +++ lib/sqlalchemy/databases/mssql.py (working copy)
> @@ -991,7 +991,7 @@
>
On Thu, Apr 30, 2009 at 8:36 AM, Tom Wood wrote:
>
> Hi Lucas,
>
> I don't think #1350 applies here, but just in case, I "pass"-ed out
> the mssql dialect do_begin per the suggestion in the discussion thread
> referenced by that ticket: no impact on the invalid cursor state
> exception.
>
I gues
Hi Lucas,
I don't think #1350 applies here, but just in case, I "pass"-ed out
the mssql dialect do_begin per the suggestion in the discussion thread
referenced by that ticket: no impact on the invalid cursor state
exception.
-Tom
> Can you read over this ticket and see if maybe you are
> affe
On Apr 29, 2009, at 10:08 AM, Tom Wood wrote:
>
> Some additional info, and a possible fix:
>
> I can reproduce this problem running the SQLAlchemy dialect unit
> tests. Using a trunk (r5930) checkout, FreeTDS 0.82 with tds protocol
> version 8.0, pyodbc 2.1.4, Python 2.5 and SQL Server 2005,
On Wed, Apr 29, 2009 at 9:08 AM, Tom Wood wrote:
>
> Some additional info, and a possible fix:
>
> I can reproduce this problem running the SQLAlchemy dialect unit
> tests. Using a trunk (r5930) checkout, FreeTDS 0.82 with tds protocol
> version 8.0, pyodbc 2.1.4, Python 2.5 and SQL Server 2005,
Some additional info, and a possible fix:
I can reproduce this problem running the SQLAlchemy dialect unit
tests. Using a trunk (r5930) checkout, FreeTDS 0.82 with tds protocol
version 8.0, pyodbc 2.1.4, Python 2.5 and SQL Server 2005, I see three
test failures in dialect.mssql:
test_binary fai
Lucas,
Thanks for taking a peek at this!
My connection string looks like: 'mssql://user:p...@server/db?
driver=FreeTDS_82&Servername=MyServer'
where FreeTDS_82 is defined in my odbcinst.ini, and MyServer is
defined in my freetds.conf.
I've tried 'tds version = 8.0' and 'tds version = 7.0' in m
On Mon, Apr 27, 2009 at 10:01 AM, Tom Wood wrote:
>
> Hi all,
>
> Am having a problem with SQLAlchemy 0.5.3 and MSSQL. Running on a
> Debian stack, using FreeTDS 0.82, pyodbc 2.1.4, Python 2.5 and
> (separately) SQL Server 2000 and SQL Server 2005.
>
> The (nose) test below fails with the except
21 matches
Mail list logo
