Tim -- For me: jeff.url...@gmail.com
Thanks!
--
Jeff Urlwin
Vice President, CISSP
CACI, Inc. -- Commercial
Office: 703-642-4521
Cell: 571-329-0499
On 4/3/13 10:14 AM, "Tim Bunce" wrote:
>I want to get the attribution for committers in the git history right.
>
>H
It's been a while since I've had time to lurk out here...
Is anyone out there using Oracle's (10g and above) Proxy authentication?
Our team is using it, also with Enterprise Users (LDAP/OID based user
list) with some success in Java/web applications.
I spent a little time and got DBD::Oracle t
>
> dbi-dev'ers - I'd be grateful if anyone on slightly unusual
> platforms (including Win32 :) could test the current code in
> svn to see if anything upsets your compiler. Thanks.
No adverse affects on Win32. Note, that by default, Win32 is not using any
picky modes to
find such issues, so
Thanks. Applied.
Jeff
> -Original Message-
> From: Steffen Goeldner [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 08, 2005 3:36 AM
> To: Jeff Urlwin
> Cc: dbi-dev@perl.org
> Subject: DBD::ODBC: MANIFEST.SKIP
>
>
> Hi Jeff,
>
> attached is a
That's probably the best thing, but there are probably more places... After
reviewing the
code, I think I don't like the duplication of the henv -- but the short term
patch is
whenever you see a SQLFreeEnv, also set the imp_dbh->henv to SQL_NULL_ENV.
Sorry I
haven't looked at better than that,
>
> Yes, another release candidate!
>
Looks good here. Pretty consistent reauth not working when ORACLE_USERID_2 not set
;). I
guess I didn't notice before -- patched to give reason and fix spelling issues. Minor
patch, so I submitted. Reauth doesn't seem to work with remote servers...i.e.
s
I'm not sure I can do much about the wrapping, other than attach it. Do
attachments work better? Is it better for you to give me rights to update
DBI?
Jeff
> -Original Message-
> From: Tim Bunce [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 09, 2004 2:03 PM
>
>
> In terms of why I'm banging on about file descriptors, let me explain
> my itch. I work on very highly scalable network applications that
> process thousands of concurrent connections. In these
> programs NOTHING
> can block my event loop, because everything falls apart if I
> do. And I
Doh. Yes. Didn't think about File::Spec and devnull()...I learn something
new every day. -- yet it seems that it's still not fast enough ;)
Jeff
>
> Could you rework that using File::Spec?
>
Index: t/01basics.t
===
--- t/01basic
Tim,
Attached is a minor patch to fix skipping tests on Win32.
It would be nice if Cygwin users could validate this on their platform...
Regards,
Jeff
Index: t/01basics.t
===
--- t/01basics.t(revision 452)
+++ t/01basics
>
>
> This message follows after my last "commoditization
> suggestion #1" email.
>
> For a context, I reference this portion of the DBI user
> documentation, under disconnect():
>
> The transaction behaviour of the disconnect method is, sadly,
> undefined. Some database systems (such
> Comments welcome.
Just some random thoughts that came from reading this.
What about Multiple result set statements/more_results? (i.e. select * from
foo; select * from bar; or calling stored procs which have multiple
statements within them as per Sybase & SQL*Server, etc)
[snip]
>
> =head2
>
> On Wed, Jul 14, 2004 at 09:59:40PM +0100, Tim Bunce wrote:
> >
> > > t/30longDBD::Oracle::db ora_lob_append failed:
> > > ORA-00600: internal error code, arguments: [122231], [],
> [], [], [],
> > > [], [], [] (DBD ERROR: OCILobWriteAppend) at t/30long.t line 317.
>
> Um,
>
>
> Thanks. I;ve applied something like that. Let me know if it's
> okay for you.
Worked for me.
Jeff
>
> Tim.
>
> On Mon, May 24, 2004 at 03:41:49PM -0400, Jeff Urlwin wrote:
> > This is having trouble getting through to [EMAIL PROTECTED]
> >
This is having trouble getting through to [EMAIL PROTECTED]
Jeff
-Original Message-
From: Jeff Urlwin [mailto:[EMAIL PROTECTED]
Sent: Monday, May 24, 2004 11:19 AM
To: '[EMAIL PROTECTED]'
Subject: DBI Patch [SVN version] fix for t\10examp.t
Tim,
As I discussed in my e-mails
Tim,
As I discussed in my e-mails regarding DBI issues when I tried to build, the
following patch allows me to test and build successfully, with your
threading update in place. The second line change is not necessary to make
things pass, but it seems more reasonable to me to make the description
>
> This is quite long because I've tried to consider all the issues.
Yes, you have. Sorry I couldn't respond to this earlier.
>
> =head2 Skipping Non-SELECT Results
>
> When executing stored procedures, for example, applications
> are sometimes only interested in the results of SELECT
> st
se (I don't have my book handy) but certainly there
> will be some get_info() items designated as mandatory for
> drivers which support more_results().
Internally, DBD::ODBC uses SQLGetFunctions(SQL_API_SQLMORERESULTS) to
determine if SQLMoreResults is supported, but get_info(36) wi
Tim,
Looks good here on ActiveState perl 809.
Regards,
Jeff
>
> A release candidate is available for testing at:
>
> http://homepage.eircom.net/~timbunce/DBI-1.42-rc2-20040311.tar.gz
Compile error on Win32, AS perl 809. The attached patch fixes it.
Tested with DBD::ODBC (SqlServer, DB2, Oracle, Access), DBD::DB2 and
DBD::Oracle (1.16 from svn).
J
>
> A release candidate is available for testing at:
>
> http://homepage.eircom.net/~timbunce/DBI-1.42-rc1-20040309.tar.gz
Got it and still have the problem with DBD::Oracle on Win32. DBI 1.41
doesn't have the issue with the same DBD::Oracle, so I'm still looking at
it. Do not know, at this
>
> On Monday 08 March 2004 12:41 am, Tim Bunce wrote:
> > On Sun, Mar 07, 2004 at 08:25:17PM -1000, [EMAIL PROTECTED] wrote:
> > > The followint patch implements PERL_NO_GET_CONTEXT for DBI (cvs
> > > version #200).
> >
> > Beau, am I right in thinking that if the DBI was built with
> > PERL_NO
>
> >
> > I think I've found a (small) problem in the execute_for_fetch
> > POD (ver. 1.41), in the example there's an extraneous
> $ins->execute()
> > (either that, or I still don't understand how this works):
> >
> >
> > my $sel = $dbh1->prepare("select foo, bar from table1");
> > $sel-
>
> I think I've found a (small) problem in the execute_for_fetch
> POD (ver. 1.41), in the example there's an extraneous $ins->execute()
> (either that, or I still don't understand how this works):
>
>
> my $sel = $dbh1->prepare("select foo, bar from table1");
> $sel->execute;
> my $ins
> p.s. Are you getting the svn change emails? I've not seen any
> since Feb 23. I'll ask Rob about it.
>
I haven't seen them.
> >
> > SQLEXT.H:/* SQL_CURSOR_TYPE options */
> > SQLEXT.H:#define SQL_CURSOR_FORWARD_ONLY 0UL
> > SQLEXT.H:#define SQL_CURSOR_KEYSET_DRIVEN1UL
> > SQLEXT.H:#define SQL_CURSOR_DYNAMIC 2UL
> > SQLEXT.H:#define SQL_CURSOR_STATIC 3UL
> > SQLEXT.H:#define SQ
Tim,
Would you mind if DBI held constants, exportable via sql_types for
SQL_CURSOR_X.
I have a patch submitted to me for DBD::ODBC which allows multiple queries
to run concurrently under SQL*Server. The patch coerced someone using it
to:
use DBI;
use DBD::ODBC;
my $dbh = DBI->connect($DS
>
> On Mon, 2004-02-23 at 14:36, Jeff Urlwin wrote:
>
> > > Which raises another issue: at present DBD::Teradata allocates a
> > > $row
> > array with a size equal to the sum of the number of >
> columns for each
> > statement. I'
>
>
> >>
> >> Also, I'd like DBI v2 to have an official method to 'reset' a
> >> statement handle back to its virgin state so that an official
> >> more_results() method can be added.
> >
> > That would be good -- and it would be good to consistently
> handle it
> > -- as best as possible.
>
>
>
> [CC'd to dbi-dev as it's of general interest. I trust that's okay.]
Yep.
[snip]
> > However, I have some issues with that -- and they may only
> be mine.
> > The cacheing is not working on this and due to the way I've
> > implemented DBD::ODBC and SQLMoreResults(). My first call to m
> On Sat, Feb 21, 2004 at 08:39:24PM -0500, Jeff Urlwin wrote:
> > I've been lurking through the $sth->{NAME} issues and it
> seems to me
> > that the current behavior of DBD::ODBC is onerous. If
> dbd_describe()
> > fails, it croaks (which is what DBD::Or
I've been lurking through the $sth->{NAME} issues and it seems to me that
the current behavior of DBD::ODBC is onerous. If dbd_describe() fails, it
croaks (which is what DBD::Oracle does).
If we return a Nullsv at this point, the end application does *not* get an
undef reference, rather it gets a
Tim,
This patch averts a small warning emitted when running Makefile.PL from the
current subversion repos. (Hey -- at least someone is using it!!!)
Also, I have a minor request. When you release release candidates, I'd like
to know the subversion repository version. Mostly because I'd like to k
>
> [CC'd to dbi-dev]
>
> On Mon, Feb 02, 2004 at 04:28:45AM -0500, Jeff Urlwin wrote:
> > Tim,
> >
> > Can you tell me exactly which commands you used?
>
> If you just want to get a copy to look at or patch you'd just to
>
> svn che
ftp.esoftmatic.com should be back up now... I had a UPS die badly and since
died, the original server stopped working.
Please let me know on the dbi-users mailing list if you have issues.
Also, since the original announcement, I have upgraded to DBI version 1.40,
DBD-Oracle 1.15 and added DBD-DB
>
> My initial purpose for suggesting such a test suite was the
> initial difficulty I had when I first wrote a DBD: docs were pretty
> thin, and there was a lot of painful trial and error. And I'm
> certain I'm *still* not in conformance in a lot of places
> (esp. as DBI API changes roll out)
>
> On Thu, Jan 22, 2004 at 02:02:45PM -0500, Jeff Urlwin wrote:
> > My initial input would be:
> >
> > Ensure that we have proper goals!!!
> >
> > Is this going to be a DBI conformance test or a driver test
> suite? I
> > belive those a
My initial input would be:
Ensure that we have proper goals!!!
Is this going to be a DBI conformance test or a driver test suite? I belive
those are two different (but not incompatible) goals. A conformance test
would be more simple, in that it would test the interface to the driver not
necessar
May I suggest that we make this either part of DBI or DBI::DriverTest and
that it's available via Subversion or CVS so that many can contribute? I
may be able to contribute some of my tests, for example, but I certainly do
not have time to be responsible for it.
Regards,
Jeff
> -Original M
>> Works on Perl 5.6.1, MSWin32, Borland 5.5, Oracle 8.1.7, except the
>> LONG issue:
>>
>> t\base...ok
>> t\cursor.ok
>> t\generalok
>> t\long...ok 59/372# failed test 60 at line 328. t\long...ok
>> 61/372# failed test 68 at line 328.
>
>New bug triggered by NLS lang I thi
>
> On Mon, Jan 12, 2004 at 05:53:00PM -0500, Jeff Urlwin wrote:
> > > Plans:
> > >
> > > 1. Move DBI source code to http://sourceforge.net/projects/dbi/
> >
> > Tim,
> >
> > On and Off I've thought about moving DBD::ODBC to a
> Plans:
>
> 1. Move DBI source code to http://sourceforge.net/projects/dbi/
>
Tim,
On and Off I've thought about moving DBD::ODBC to a CVS repository and
searched for a tool that would take old tarballs of prior releases and build
the CVS repository from the tarballs. Maybe I don't need to,
>
> Almost 4 months after the previous release candidate, and 10
> months after the last full release, here's another release candidate:
>
>
> http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc2-20040
> 112.tar.gz
Works ok on Oracle 9.2.0.4.0 on Solaris (32 bit) except the varchar tri
>
> Almost 4 months after the previous release candidate, and 10
> months after the last full release, here's another release candidate:
>
>
> http://homepage.eircom.net/~timbunce/DBD-Oracle-1.15-rc2-20040
> 112.tar.gz
Works here Windows XP, ActiveState Perl 5.8.2 (build 807), DBI 1.40.
R
>
> In his announcement for DBD::Ingres-0.51 Henrik says:
>
> > The DBI docs state that swtiching the value of
> $dbh->{AutoCommit} from
> > off to on should cause a $dbh->commit to be called, but setting
> > $dbh->{ing_rollback} to on will cause a $dbh->rollback to be called
> > instead.
>
>
>
> On Wed, Sep 24, 2003 at 11:24:17AM +0200, Steffen Goeldner wrote:
> > Tim Bunce wrote:
> > >
> > > Is it an alpha or a beta? Who knows? Probably more alpha
> than beta
> > > but it it what it is and you're welcome to hit on it.
> >
> > Perl 5.6.1, MSWin32, Borland 5.5, Oracle 8.1.7
> >
>
> I've just spotted that the Driver.xst for do() is flawed.
> The dbd_db_do4() function can't return a row count, only true
> or false.
>
> Are any drivers using it?
Only via generated code in ODBC.c, from ODBC.xs
>
> To check you could grep the driver source files (*.[ch] etc)
> for dbd_d
>
> > Makefile:309: *** missing separator. Stop.
Yep. Martin already caught that one and I've patched it here for release.
Thanks. Dumb, but MS NMAKE.exe didn't catch it.
Jeff
Thanks. Done in the next version of DBD::ODBC.
Regards,
Jeff
> -Original Message-
> From: Steffen Goeldner [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2003 6:12 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: DBD-ODBC-1.05: dmake.exe: Error -- Don't know how to
>
>
> On Tue, May 27, 2003 at 10:16:30AM -0400, Jeff Urlwin wrote:
> >
> > Tim -- should the DBISTATE_VERSION have been bumped when the new
> > calls/calling changed in 1.33? I'm suspecting that DBD::ODBC was
> > built with version 1.33+ and yet he's
Thanks. Fixed!
Jeff
>
>
> On Mon 17 Mar 2003 14:39, "H.Merijn Brand"
> <[EMAIL PROTECTED]> wrote:
> > > Cleaned up Makefile.PL and added Informix support thanks to
> > > Jonathan Leffler (see README.informix)
>
> DBD-ODBC-1.05/t/ODBCTEST.pm
> DBD-ODBC-1.05/t/02simple.t.org
> sort (...) int
>
> On Mon 17 Mar 2003 15:24, "Jeff Urlwin"
> <[EMAIL PROTECTED]> wrote:
> > Sorry...try the attached replacement for t/02simple.t. I fixed it
> > post release.
> >
> > Let me know if you have problems.
>
> Success OK too? :) This is Cygwin-1.3.22s (blead) on Win2k. Thanks.
Always :)
Jeff
Sorry...try the attached replacement for t/02simple.t. I fixed it post
release.
Let me know if you have problems.
Jeff
> -Original Message-
> From: H.Merijn Brand [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 17, 2003 8:39 AM
> To: Jeff Urlwin
> Cc: DBI developer
>
> On Thu, Mar 13, 2003 at 01:09:25AM -0500, Jeff Urlwin wrote:
> > >
> > >
> > > Yes. You're right that NAME_uc/NAME_lc and their *_hash
> > > variants need to be cleared from the cache. May actually be
> > > good to work the other w
hv_delete((HV*)SvRV(inner), key, keylen, G_DISCARD);
}
}
}
Jeff
>
> On Tue, Mar 11, 2003 at 11:48:12AM -0500, Jeff Urlwin wrote:
> > FYI -- did you see this message on DBI-users? I received a strange
> > bounce message and I'm c
Bunce [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 12, 2003 7:25 PM
> To: [EMAIL PROTECTED]
> Subject: Beta release of DBD::Oracle: DBD-Oracle-1.13-20030313.tar.gz
>
>
> With many thanks due to Jeff Urlwin, I've been able to get
> back into DBD::Oracle development a
3 7:25 PM
> To: [EMAIL PROTECTED]
> Subject: Beta release of DBD::Oracle: DBD-Oracle-1.13-20030313.tar.gz
>
>
> With many thanks due to Jeff Urlwin, I've been able to get
> back into DBD::Oracle development after 18 months of, er, stability!
>
> I've made
>
> On Sat, Mar 08, 2003 at 07:24:59PM -0500, John Siracusa wrote:
> > Just a quick question on the topic. How far are you
> willing to go (or
> > willing to let DBD authors go) to support the API you're planning?
>
>|< this far >|
>
> :)
>
> > For example, Postgres has a SERIAL
>
> In order to check how DBD does the new DBI tricks, so I might
> find time to update DBD::Unify to do alike, I tried to
> install it under Cygwin on my W2k box, but I hit a limit that
> I did not see before:
>
>
> /usr/bin/perl.exe "-MExtUtils::Command::MM" "-e"
> "test_harness(0, 'blib/l
>
> DBD::Sybase *will* work with FreeTDS (mostly), although
> recent versions of DBD::Sybase implement a lot of things that
> don't exist in the FreeTDS libs (yet), such as RPC calls for
> stored procedures, text/image updating via ct_send_data(), etc.
>
> > Is it that you want to dedicate mor
[heavily snipped]
>
> It takes the output from DBD::ODBC's type_info_all method and
> maps it writes a new copy of the hash. I actually wrote it
> to handle the extra attributes you documented, and was
> pleasantly surprised to find DBD::ODBC 1.01 already providing
> the extra attributes (pos
>
> Yeap. I don't envy you task. You're life will be easier if
> you get the latest Informix ODBC driver and the latest
> DBD::ODBC (development release I think) and see how they
> behave. The implementors of Informix's ODBC driver must have
> faced many of these issues and addressed them in a
>
> On Mon 09 Dec 2002 18:11, "H.Merijn Brand"
> <[EMAIL PROTECTED]> wrote:
> > On Mon 09 Dec 2002 05:29, "Jeff Urlwin" <[EMAIL PROTECTED]>
> > wrote:
> > > Version 1.0 of DBD::ODBC is finally out!
> > >
> > > Th
>
> On Mon 09 Dec 2002 05:29, "Jeff Urlwin"
> <[EMAIL PROTECTED]> wrote:
> > Version 1.0 of DBD::ODBC is finally out!
> >
> > This is a significant update of the DBD::ODBC module over
> the latest
> > non-developer release DBD::ODBC 0.4
Tim,
Attached is my patch for building DBD::Oracle 1.12 on Win32. This patch
simply extends the current logic to look for the "default" home in the
registry (Used 8.1.7 with a single home and multiple homes to test and
9.2 with multiple homes). My problem was that I was transferring a
bunch of s
> Other DBD::* modules require DBI_DSN, DBI_USER, DBI_PASS to run the
> tests. Without the correct setup installing from CPAN will fail.
The most recent versions of DBD::ODBC's tests, however, gracefully handle
DBI_DSN being undefined for just this purpose (and ActiveState's repository
builds, t
>
> On Wed, Nov 20, 2002 at 10:30:00PM -0800, David Wheeler wrote:
> > On Wednesday, November 20, 2002, at 06:53 AM, Tim Bunce wrote:
> >
> > >>But if I change it (as I'm seriously considering, in light of
> > >>PostgreSQL 7.3's support for prepared statements), I'll probably do no
> > >>parsing f
>
> On Wednesday, November 20, 2002, at 04:51 AM, H.Merijn Brand wrote:
>
> > I've added a driver specific verbose setting to be able to see driver
> > specific
> > debugging. IIRC, Tim didn't agree with the name, so I have to change it
> > sometime, but - certainly in the development phase - it m
> >> Maybe it's just too complex, because, looking at DBD::ODBC's
> >> dbd_preparse(), the handling of literals in the query seems a good
> >> deal
> >> more straight-forward (though it doesn't appear to handle '\'' or "\""
> >> -- am I reading that right?
> >
> > Nope, it handles " or '.
> >
> >
>
>
> On Tuesday, November 19, 2002, at 03:42 PM, Jeff Urlwin wrote:
>
> > You probably only need dTHR to support older, pre-threading perls. I
> > don't
> > believe you need the #ifdef, but it can't hurt (except visually in your
> > code).
>
>
David -- I'll pipe in where I can...
>
> * In several of the functions, DBD::Pg starts with the statement
> "dTHR;". DBD::mysql, meanwhile, starts with this:
>
> #ifdef dTHR
>dTHR;
> #endif
>
> Which is correct, and what is this thing (variable) for?
You probably only need dTHR to support old
>
> H.Merijn Brand wrote:
> > On Thu 24 Oct 2002 14:34, "Jeff Urlwin"
> <[EMAIL PROTECTED]> wrote:
> >
> >>That is a bug in Perl, I think... I don't get that here and
> I'm using DBI
> >>1.30 on various platforms. It'
That is a bug in Perl, I think... I don't get that here and I'm using DBI
1.30 on various platforms. It's a simple
use DBI 1.201;
It's been tested on Perl 5.8, ActivePerl, 5.6.1, etc...
What is bleadperl?
Regards,
Jeff
>
> Cygwin-1.3.14-1 on Win2k-sp3 with bleadperl
>
> DBI version 1.201 re
Thanks Tim. I can make this a patch for the future, if it works for
Prasanna.
Jeff
>
>
> On Mon, Sep 23, 2002 at 02:56:55PM -0400, Jeff Urlwin wrote:
> > Prasanna,
> >
> > 1) please always copy dbi-users.
> > 2) in Makefile, (not Makefile.PL) change:
> &
rrent code.
I have no definite timeline for that, but I want to do it soon. It's now
just a matter of time for me to get it.
Regards,
Jeff
> -Original Message-
> From: Vassiliy Truskov [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 19, 2002 11:25 AM
> To: '
>
> On Monday, September 9, 2002, at 03:16 PM, Jeff Urlwin wrote:
>
> > Not specifically, but maybe I'm missing something. If HandleError is
> > called, shouldn't the result of $attr->{HandleError} be checked before
> > trying to RaiseError or PrintErro
>
> On Wed, Aug 21, 2002 at 09:59:23PM -0700, David Wheeler wrote:
> > Hi All,
> >
> > I'd like to submit a simple patch that causes the DBI connect() method
> > to execute a HandleError code reference if it has one. There's a
> > comment suggesting that it could be added, and it makes sense to me
I
think this can be shaped to fit the bill.
Thanks!
Jeff
> -Original Message-
> From: Gerald Richter [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 30, 2002 2:18 AM
> To: Jeff Urlwin; Tim Bunce
> Cc: [EMAIL PROTECTED]
> Subject: Re: Trouble in Update while shar
Gerald,
Do you have a short test script at all?
Thanks,
Jeff
>
>
> Hi Tim,
>
> > >
> > > I know it isn't an easy thing. My main hope was that the error message
> at
> > > the end of my report
> > >
> > >
> > > > > *** Internal ERROR kghubatchfree_01 [0x1ecb290]
> ***
> > > > >
anything from me.
Well -- I would suggest that if it fixes your problem, let's move on and
I'll keep making it work. Besides, I'm getting the feeling that if I get it
working for you flawlessly, then I'll get it working right overall :)
Now -- a question for you: would yo
>
> On 20-Aug-2002 Jeff Urlwin wrote:
> > I've been thinking a bit more about this.
> >
> > It *may* be a "reasonable" thing, for now, to:
> > - "silently" eat result sets without columns (i.e. count of rows
> > inserted/d
I've been thinking a bit more about this.
It *may* be a "reasonable" thing, for now, to:
- "silently" eat result sets without columns (i.e. count of rows
inserted/deleted/updated)
- provide multiple result sets to the user via the odbc_more_results
attributed
- automatical
-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of [EMAIL PROTECTED]
> Sent: Monday, August 19, 2002 1:35 PM
> To: Jeff Urlwin
> Cc: [EMAIL PROTECTED]; Joe Tebelskis
> Subject: RE: Multiple Result sets in DBD::ODBC (and others?)
>
>
>
> On 19-Aug-20
nday, August 19, 2002 10:43 AM
> To: Jeff Urlwin
> Cc: Joe Tebelskis
> Subject: RE: CPAN Upload: J/JU/JURL/DBD-ODBC-0.45_14.tar.gz
>
>
> I will think about this more but my immediate thought is that the
> problem is
> the lack of SQLMoreResults in DBI/DBD::ODBC. If the
>
> > Please look at line 35 of the Makefile.PL. That's being executed on my
> > 5.8.0 (on Suse Linux, self compiled). Is that not being
> executed for some
> > reason on your machine or does the way I'm doing it cause a problem?
>
> Ok in fact your prereqs are ok. The trouble is at top of Makef
> > >
> > > Is this during 'global destruction' (ie when a program is exiting)?
> >
> > Yep. So far ;-)
>
> I'm sure it'll only ever affect global destruction (unless
> there's a bug in
> your code or a very serious bug in perl's).
Could be me :).
> > > > I'd like to gather some wisdom from th
::CheckSV($handle);
# $count8 = Devel::Leak::NoteSV($handle);
print "$count, $count2, $count3, $count4, $count5, $count6, $count7,
$count8\n";
Jeff
> -Original Message-
> From: Tim Bunce [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 29, 2002 4:39 PM
> To: Jeff Urlwin
>
nd/or with an older DBD::ODBC version.
>
> > How does one use the Devel::Leak module to the best advantage?
>
> Read the docs. It's not too complicated
> http://search-beta.cpan.org/author/NI-S/Devel-Leak/Leak.pm
>
> Tim.
>
> > It may be the easiest w
Gary -- it's more likely in DBD::ODBC than DBI. If you can create a
self-contained sample, it would be greatly appreciated and looked at faster
:)
You didn't indicate if the loop is a set of inserts, queries, etc. Does it
have longs? What's the LongReadLen value?
If you can, include a drop ta
FYI
>
> > As an additional question - how many drivers actually impelement
> > column_info() ?
>
> DBD::ODBC does, I think, DBD::Oracle is about to. Others will follow.
>
DBD::ODBC as of the version being released tonight, does :). DBD::ODBC
implemented a function columns which did the same wor
; To: [EMAIL PROTECTED]
> Cc: Thomas A. Lowery; Jeff Urlwin
> Subject: [Fwd: DBD::ADO and DBD::ODBC with foxpro driver problem]
>
>
> I decided to forward this to dbi-dev. I realise this is probably a
> problem with the FoxPro ODBC driver but I need a fix. Please help.
>
Just as an FYI -- I was thinking about the same thing recently. That is:
Moving DBD::ODBC to use SQLExtendedFetch and allowing multiple rows to be
cached locally, hopefully in less network trips ;)
I'd like to work towards implementing the direct support in DBI (unless I'm
missing something) as
inserting images
into your database, please check here.
The uploaded file
DBD-ODBC-0.39.tar.gz
has entered CPAN as
file: $CPAN/authors/id/J/JU/JURL/DBD-ODBC-0.39.tar.gz
size: 66130 bytes
md5: 91ec9b13e59dc298eb2cf6592f03eaa0
No action is required on your part
Request entered by: J
As far as DBD::ODBC is concerned, it's a private patch that is in progress.
It's taken me a bit longer because of concurrent patches to the same area of
code. That, and the DBI spec isn't there, although I plan to implement as a
set of private functions. It's on my list and a patch from the late
Ok, after the discussion ended, I just took this patch as it stands.
Thanks!
Also -- I will release a new version shortly, as I have NOT received any
answer from ActiveState as to why they haven't updated DBD::ODBC. Thus, I
intend to move on...
Also -- Steffen, I'm setting up a machine with Ora
, 2002 5:27 AM
> To: Jeff Urlwin
> Cc: [EMAIL PROTECTED]
> Subject: Re: DBD::ODBC: connect() attributes
>
>
> Jeff Urlwin wrote:
> >
>
> > Are you not getting ODBC 3.x behavior by default?
>
> Yes, at least for the Oracle ODBC driver.
> In the past I used
Steffen,
Thanks!
Are you not getting ODBC 3.x behavior by default?
Jeff
> -Original Message-
> From: Steffen Goeldner [mailto:[EMAIL PROTECTED]]
> Sent: Monday, February 25, 2002 3:56 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: DBD::ODBC: connect() attributes
>
>
>
Steffen,
Thanks, but, er, why, I wonder? Do you have tracing on when using one of
the machines? Do you have a different ACCESS driver?
Thanks,
Jeff
> -Original Message-
> From: Steffen Goeldner [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 15, 2002 11:49 AM
> To: [EMAIL PROTECT
Steffen,
I can't seem to find DBI::Const??? I checked CPAN and to see if my DBI
distribution had it.
Any pointers would be welcome.
Thanks,
Jeff
> -Original Message-
> From: Steffen Goeldner [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 12, 2002 4:35 AM
> To: [EMAIL PROTECTED]
February 12, 2002 7:23 AM
> To: Jeff Urlwin
> Cc: [EMAIL PROTECTED]
> Subject: Re: DBD::ODBC: get_info(), strange results
>
>
> Jeff Urlwin wrote:
>
> > Martin,
> >
> > Is this really a necessary/useful SQLGetInfo for DBI? I don't
> seem to think
>
1 - 100 of 131 matches
Mail list logo
