Rick Morrison wrote:
>
> I was thinking of a user-level option for liveliness checking on pool
> checkout, with dialect-specific implementations (e.g. execute a 'SELECT
> 1', or something more efficient if the driver allows). Is that in line
> with what you were thinking?
>
>
>
>
>
> I was thinking of a user-level option for liveliness checking on pool
> checkout, with dialect-specific implementations (e.g. execute a 'SELECT
> 1', or something more efficient if the driver allows). Is that in line
> with what you were thinking?
>
I had in mind something more of a optimis
Rick Morrison wrote:
> Sounds nice, thanks for the heads-up.
>
>
> > There'll be opportunities for dialects to set up pool events as well.
>
> One of the things I'm looking to see is better reconnect support for
> dead database connections from network partitions, sql server restarts,
> etc.
Sounds nice, thanks for the heads-up.
> There'll be opportunities for dialects to set up pool events as well.
One of the things I'm looking to see is better reconnect support for dead
database connections from network partitions, sql server restarts, etc.
Is that going to be fully Dialect contr
Rick Morrison wrote:
> There's a Dialect refactor underway for 0.5.0 that will likely change
> the way that options are fed to db engines:
Currently the munging of url params and connect_args into a connect()
lambda is happening outside of the dialect's control. In 0.5 that's all
moving into
There's a Dialect refactor underway for 0.5.0 that will likely change the
way that options are fed to db engines:
http://groups.google.com/group/sqlalchemy/browse_thread/thread/36fd2e935b165d70
Part of that work will probably have some influence on the dburi and
create_engine(**kwargs) option sp
On Tue, Apr 22, 2008 at 9:35 AM, Lukasz Szybalski <[EMAIL PROTECTED]> wrote:
> >
> > e = sqlalchemy.create_engine("mssql://xxx:[EMAIL
> PROTECTED]:1433/xx?driver=TDS&odbc_options='TDS_Version=8.0'")
>
> here is a patch to mssql.py that makes above line work.
>
> 805c805,808
>
> <
Look, relax:
No one is suggesting that we *eliminate* DSN-less connections, only to come
up with a reasonable *default* for ODBC connection specifications. A
mechanism for non-DSN connections will certainly be provided.
>
> Well,
> Based on :
> http://www.4guysfromrolla.com/webtech/070399-1.shtm
On Wed, Apr 23, 2008 at 7:07 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
> On 2008-04-18 18:01, Rick Morrison wrote:
> >> Reading this thread, I keep wondering why you are trying to put
> >> all that connection setup configuration into the connection string...
> >>
> >> Such setting are no
>
> e = sqlalchemy.create_engine("mssql://xxx:[EMAIL
> PROTECTED]:1433/xx?driver=TDS&odbc_options='TDS_Version=8.0'")
here is a patch to mssql.py that makes above line work.
805c805,808
< connectors.append(keys.pop('odbc_options'))
---
> odbc_options=keys.pop('odbc_opt
nope. Seems like the SQLA connection is still not using the
appropriate magical incantation to get all that ODBC stuff to behave
reasonably.
might I suggest just circumventing the URL entirely and just using
creator=lambda:
pyodbc
.connect
("DRIVER
={TDS};SERVER=;UID=;PWD=
On Fri, Apr 18, 2008 at 1:36 PM, Rick Morrison <[EMAIL PROTECTED]> wrote:
> Err, on a second look, that's no good. The connect_args are passed directly
> through to connect().
>
> This thing needs to construct an ODBC connection string from some fragments
> provided by the dburi, and from some eng
Err, on a second look, that's no good. The connect_args are passed directly
through to connect().
This thing needs to construct an ODBC connection string from some fragments
provided by the dburi, and from some engine options. So we'll either need
some parsing tricks for the URL to allow strings w
On Fri, Apr 18, 2008 at 11:07 AM, jason kirtland <[EMAIL PROTECTED]> wrote:
>
> Rick Morrison wrote:
> > Yeah, I was under the impression that config args passed in via
> > create_engine() ctor and via dburi were treated the same, but looking
> > over engine/strategies.py, it looks as if they
hey thanks Jason, that's a nice shortcut.
Lukasz, can you please give that a try?
On Fri, Apr 18, 2008 at 12:07 PM, jason kirtland <[EMAIL PROTECTED]>
wrote:
>
> Rick Morrison wrote:
> > Yeah, I was under the impression that config args passed in via
> > create_engine() ctor and via dburi were t
Rick Morrison wrote:
> Yeah, I was under the impression that config args passed in via
> create_engine() ctor and via dburi were treated the same, but looking
> over engine/strategies.py, it looks as if they have two separate
> injection points. I'll see if I can get it to allow either, stay tu
Yeah, I was under the impression that config args passed in via
create_engine() ctor and via dburi were treated the same, but looking over
engine/strategies.py, it looks as if they have two separate injection
points. I'll see if I can get it to allow either, stay tuned.
On Thu, Apr 17, 2008 at 4
>
> Reading this thread, I keep wondering why you are trying to put
> all that connection setup configuration into the connection string...
>
> Such setting are normally configured in the odbc.ini file and then
> you just reference data source name in the connection string.
>
> That's the standard
On Thu, Apr 17, 2008 at 3:04 PM, Rick Morrison <[EMAIL PROTECTED]> wrote:
> It's a two-line change that pops the new keyword out of the config dict just
> like the others that were added.
>
> Mike, can you take a quick look at mssql.py line 804 and see why this might
> be complaining? I've got to
It's a two-line change that pops the new keyword out of the config dict just
like the others that were added.
Mike, can you take a quick look at mssql.py line 804 and see why this might
be complaining? I've got to run out.
On Thu, Apr 17, 2008 at 3:58 PM, Lukasz Szybalski <[EMAIL PROTECTED]>
wr
On Thu, Apr 17, 2008 at 2:35 PM, Rick Morrison <[EMAIL PROTECTED]> wrote:
>
> > Does it matter what case are the parameters? DRIVER in pyodbc, we used
> > 'driver' in previous connection strings etc...
> >
> >
> >
> >
>
> No the parameters are a straight pass-through, that traceback is complaining
>
> Does it matter what case are the parameters? DRIVER in pyodbc, we used
> 'driver' in previous connection strings etc...
>
No the parameters are a straight pass-through, that traceback is complaining
about the 'odbc_options' keyword itself. Are you sure you're running the
current trunk?
--~--~
On Thu, Apr 17, 2008 at 2:07 PM, Rick Morrison <[EMAIL PROTECTED]> wrote:
> It's in trunk r4518. Take 'er for a spin and let me know how it works out.
got an error:
e = sqlalchemy.create_engine('mssql://xxx:[EMAIL
PROTECTED]:1433/',odbc_options='DRIVER={TDS};TDS_Version=8.0')
Traceback (most
It's in trunk r4518. Take 'er for a spin and let me know how it works out.
On Thu, Apr 17, 2008 at 2:54 PM, Lukasz Szybalski <[EMAIL PROTECTED]>
wrote:
>
> On Thu, Apr 17, 2008 at 1:22 PM, Rick Morrison <[EMAIL PROTECTED]>
> wrote:
> > ok, ok, assuming that dsn-less connections actually do ignor
On Thu, Apr 17, 2008 at 1:22 PM, Rick Morrison <[EMAIL PROTECTED]> wrote:
> ok, ok, assuming that dsn-less connections actually do ignore the .conf file
> and require all that stuff to be specified.
>
> here's the question that I'm trying to ask:
>
> instead of something like this:
>
ok, ok, assuming that dsn-less connections actually do ignore the .conf file
and require all that stuff to be specified.
here's the question that I'm trying to ask:
instead of something like this:
create_engine('mssql://user:[EMAIL PROTECTED]/database',
odbc_driver='TDS', odbc_auto
On Thu, Apr 17, 2008 at 12:14 PM, Rick Morrison <[EMAIL PROTECTED]> wrote:
>
>
>
> > Here are the options as specified by free TDS. What you are talking
> > about is setting it in conf file which is used only for dsn
> > connection.
>
> No, I meant as the *default* TDS version here. See here:
>
>
> Here are the options as specified by free TDS. What you are talking
> about is setting it in conf file which is used only for dsn
> connection.
No, I meant as the *default* TDS version here. See here:
http://www.freetds.org/userguide/freetdsconf.htm
I'm talking about the [global] setting,
On Thu, Apr 17, 2008 at 10:02 AM, Lukasz Szybalski <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 7, 2008 at 4:37 PM, Rick Morrison <[EMAIL PROTECTED]> wrote:
> >
> > > The limitation here I guess is 30 char identifier limit but I will
> > > need to test it.
> >
> > Ah yeah, you're going to have b
On Mon, Apr 7, 2008 at 4:37 PM, Rick Morrison <[EMAIL PROTECTED]> wrote:
>
> > The limitation here I guess is 30 char identifier limit but I will
> > need to test it.
>
> Ah yeah, you're going to have bigger problems than 30 char identifiers with
> the Sybase TDS settings. MSSQL uses a different
> The limitation here I guess is 30 char identifier limit but I will
> need to test it.
Ah yeah, you're going to have bigger problems than 30 char identifiers with
the Sybase TDS settings. MSSQL uses a different set of wire-protocol
representations of datetime types, and your dates are going to be
On Thu, Apr 3, 2008 at 1:36 PM, Lukasz Szybalski <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 2, 2008 at 4:24 PM, Michael Bayer <[EMAIL PROTECTED]> wrote:
> > Gottit. Notice, pyodbc is truncating all the column names to 30
> characters.
> > anyway, thats why its broken. Is this a bug in pyodbc ?
On Wed, Apr 2, 2008 at 4:24 PM, Michael Bayer <[EMAIL PROTECTED]> wrote:
> Gottit. Notice, pyodbc is truncating all the column names to 30 characters.
> anyway, thats why its broken. Is this a bug in pyodbc ? I thought MS-SQL
> has a much bigger limit than this ?
I don't know if I mentioned i
On Apr 2, 2008, at 7:35 PM, Rick Morrison wrote:
> > So how would I find out if this is pyodbc or unixodbc?
>
> On Unix, it's both.
>
> pyodbc is the Python DB-API module that provides the DB-API2
> interface for sqlalchemy it in turn relies on an underlying ODBC
> layer.
>
> unixodbc is the
On Wed, Apr 2, 2008 at 6:35 PM, Rick Morrison <[EMAIL PROTECTED]> wrote:
> > So how would I find out if this is pyodbc or unixodbc?
>
> On Unix, it's both.
>
> pyodbc is the Python DB-API module that provides the DB-API2 interface for
> sqlalchemy it in turn relies on an underlying ODBC layer.
>
>
On Apr 2, 2008, at 7:22 PM, Rick Morrison wrote:
>
> > hey not to be impolite, but I burned a little oil on this one too,
> ya know.
>
absolutely ! oil burned all around.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
> So how would I find out if this is pyodbc or unixodbc?
On Unix, it's both.
pyodbc is the Python DB-API module that provides the DB-API2 interface for
sqlalchemy it in turn relies on an underlying ODBC layer.
unixodbc is the ODBC-for-Unix implementation that provides an ODBC interface
(the ODBC
On Wed, Apr 2, 2008 at 6:22 PM, Rick Morrison <[EMAIL PROTECTED]> wrote:
> > also of concern is that, nobodys ever going to know they need to use this
> parameter when this issue arises.
>
> Well the idea is that this is a workaround for what I suspect is a broken
> Unix + pyodbc configuration, no
> also of concern is that, nobodys ever going to know they need to use this
parameter when this issue arises.
Well the idea is that this is a workaround for what I suspect is a broken
Unix + pyodbc configuration, not a long-term solution.
its only because I narrowed the issue down to where I knew
On Apr 2, 2008, at 7:06 PM, Rick Morrison wrote:
> > you can mix both freely. any class that has max_identifier_length
> on it, if you set self.max_identifier_length, that overrides it.
>
> Oh ok, nice.
>
> Alright, this is in trunk r4429 as a keyword parameter named
> "max_identifier_lengt
On Wed, Apr 2, 2008 at 6:06 PM, Rick Morrison <[EMAIL PROTECTED]> wrote:
> > you can mix both freely. any class that has max_identifier_length on it,
> if you set self.max_identifier_length, that overrides it.
>
> Oh ok, nice.
>
> Alright, this is in trunk r4429 as a keyword parameter named
> "ma
> you can mix both freely. any class that has max_identifier_length on it,
if you set self.max_identifier_length, that overrides it.
Oh ok, nice.
Alright, this is in trunk r4429 as a keyword parameter named
"max_identifier_length"
Lukasz: to use it, add the "max_identifier_length" as a keyword
42 matches
Mail list logo