you
drop into "C:\Perl\site\lib".
What's the best way to make this available? What issues do I need to
consider?
-Original Message-
From: Martin Gainty [mailto:[EMAIL PROTECTED]
Sent: Friday, August 31, 2007 6:13 PM
To: CAMPBELL, BRIAN D (BRIAN); Jonathan Leffler; DBI Use
FYI...
While Jonathan doesn't support DBD::Informix on Windows, I have been
able to take his source and build a Windows version that works with
ActiveState Perl. For two different versions if DBD::Informix, the most
recent version being 200502. So it is possible, but requires the proper
windows
riginal Message-
From: Bill Moseley [mailto:[EMAIL PROTECTED]
Sent: Friday, June 29, 2007 4:58 PM
To: CAMPBELL, BRIAN D (BRIAN)
Cc: dbi-users@perl.org
Subject: Re: escaping % AND \%
On Fri, Jun 29, 2007 at 03:03:42PM -0500, CAMPBELL, BRIAN D (BRIAN)
wrote:
> Then if you want all chars to be
Then if you want all chars to be treated literally, then I presume you
want:
\%
To be translated to:
\\\%
So just adding your $esc to the left part of s/// should do the trick,
right?
-Original Message-
From: Bill Moseley [mailto:[EMAIL PROTECTED]
Sent: Friday, June 29, 2007 10:55 AM
]
Sent: Friday, May 11, 2007 7:27 AM
To: [EMAIL PROTECTED]
Cc: CAMPBELL, BRIAN D (BRIAN); [EMAIL PROTECTED];
dbi-users@perl.org
Subject: Re: temporary table "disapears"
An aside: Andon's report got me wondering if Oracle temp tables behave
correctly via DBI. My answer is: yes! Oracl
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, May 10, 2007 10:40 PM
To: CAMPBELL, BRIAN D (BRIAN)
Cc: [EMAIL PROTECTED]; dbi-users@perl.org
Subject: RE: temporary table "disapears"
You sho
Thursday, May 10, 2007 7:39 AM
To: dbi-users@perl.org
Subject: Re: temporary table "disapears"
CAMPBELL, BRIAN D (BRIAN) wrote:
> You're right. It's the the other way around from what I said.
> However, when I tested this yesterday it seemed I was getting an error
>
To: CAMPBELL, BRIAN D (BRIAN)
Cc: [EMAIL PROTECTED]; dbi-users@perl.org
Subject: RE: temporary table "disapears"
I'm pretty sure that #tmp is a local temporary table, and ##tmp
is a global temporary table...
So the origin
Actually I tried this against SQL 2000, DBI 1.53 and DBD::ODBC 1.13...
You should be getting 2 errors, the same error from both prepares. In
other words, #foo isn't being treated as a proper table name.
Naturally, these statements work fine if you just use foo (which isn't
temp).
However, #foo s
Yes, I was able to reproduce your result with this configuration:
Perl 5.8.7, DBI v1.53 and DBD::ODBC v1.13, connectiong to MSSQL2000.
Seems that any number of zeros (:0, :00, :000) will cause the "problem",
as long as it is NOT followed by any other numeric digits.
-Original Message-
Fr
Some points...
1. My response to the style 6 failure
I am also puzzled why 6 failed. The non-null case worked, but the NULL
case did not: no rows with null values were selected. After
"substitution" in:
WHERE mycol = ? OR (mycol IS NULL AND ? = 1)
Effectively, you get this for the NULL
To get PPM past the proxy, you'll need to set the env var to something
like this:
SET HTTP_proxy=http://yourproxyserver.yourcompany.com:8000
Also, I'm assuming you're using ActiveState Perl (you didn't say). In
at least one release, I recall having problems with the PPM repository
settings that
FYI, This works for me.
my $dbh = DBI->connect('DBI:ODBC:Driver={SQL
Server};server={SVR12};database={Review};');
Perl 5.8.7
DBI 1.53
DBD-ODBC 1.13
Perl is running on Windows XP, and connecting to a SQL server.
Our captilizations differ, but that's not an issue. I tried your
capitalizations an
Here's a guess, as I'm not familiar with your particular Database and DBD.
It looks like the DBD is treating your value as in integer. Perhaps the DBD
looks at the first part of the string, and thinks, "here's a number, so I'll
pass an integer type to the database engine".
Suggestion: try addi
I've done something similar to what you did...
It went something like this...
- Run query in a separate thread.
- Display dialog box to allow user to abort (instead of having fixed timeout).
- If query finishes first, close dialog box, and query thread is done.
- If user presses abort, cancel the
I've successfully connected to a local MS SQL server (MSDE actually) from
ActiveState Perl using the following connect string. This is the DSN-less form
described in the docs.
my $dbh = DBI->connect('DBI:ODBC:Driver={SQL
Server};server={(local)};database={my_db};','','');
Since your server is
One problem I see is this:
Your Windows path delimiters act as escape chars in Perl.
A couple of solutions:
Double up the backslashes, e.g. "...:c\\programme\\xamapp\\..."
Use single quotes to disable interpolation of escape chars:
'...:c\programme\xamapp\...'
-Original Message-
A bit OT, but assuming it's a linefeed issue...
UltraEdit does offer linefeed options.
You can convert files using File -> Conversion -> ...
You can tell it whether to load/save in the Unix format using Advanced ->
Configuration -> General.
-Original Message-
From: Garrett, Philip (MAN
I would not characterize perl-DBI as being slow, in general.
I would say that embedding SQL in any programming gives you flexible and
powerful access to your database. But that other techniques and tools could
give you faster performance in specific narrowly-defined situations (e.g. a
bulk dat
Regarding the first problem this former post of mine may help.
http://www.nntp.perl.org/group/perl.dbi.users/27423
-Original Message-
From: Hauptmann, Bob-P57289 [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 07, 2006 11:56 AM
To: dbi-users@perl.org
Subject: Installing DBI and DBD::Oracl
The other main reason NOT to interpolate is for security reasons.
If the interpolation value is user supplied, and you have a untrustworthy user
base, you are vulnerable from "SQL injection attacks". Do a search on that
subject if you need more background information.
-Original Message-
So, Bart, you must also have an opinion about about the Perl syntax for
declaring variables, as in:
my $dbh = DBI->connect(...);
##
:-)
-Original Message-
From: Bart Lateur [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 21, 2005 2:33 AM
To: dbi-users@perl.org
Subject: Re: ANNOUNC
You are using one "?" for many values. That won't work. You have two choices.
Insert as many "?" placeholders in the IN clause as you have @account entries.
Or,
Insert data without the "?" placeholder. In other words:
... prepare(q{... account_num in (} . $placeholder . q{)...});
And remove $p
PPM connection problems were recently addressed in a thread in this mailing
list.
Refer to http://www.mail-archive.com/dbi-users@perl.org/msg25563.html
If you are using ActiveState Perl, you *want* to get PPM to work for you to
install packages. That is the easiest way.
-Original Message-
You are are missing the DBD driver for ODBC.
What's missing from your message is what Perl you are using.
I'll presume that it is ActiveState Perl.
I'll also presume that you used the PPM tool to install DBI from an ActiveState
repository.
If true, the solution is to use PPM to install DBD::ODBC.
To use PPM to download DBI, I also had to set my http_proxy.
But I may have also had to change the repositories that were initially
configured in PPM.
So if you still can't connect you may want to try that too.
Use the PPM rep command to view and change repositories.
Refer to the Activestate docs:
, August 10, 2005 4:53 PM
To: CAMPBELL, BRIAN D (BRIAN)
Cc: DBI Users Mailing List
Subject: Re: Informix DBD build on Windows - Better
-Original Message-
On 8/8/05, CAMPBELL, BRIAN D (BRIAN) <[EMAIL PROTECTED]> wrote:
All in all I uncovered 9 bugs in the build process f
ot; in the test runs: All tests passed, except 4 were skipped and two
tests had some
failures:t\t08fork.t t\t91udts.t
How significant are
failures in these particular tests? Details available on
request.
-Original Message-From: CAMPBELL, BRIAN D (BRIAN)
[mailto:[EMAIL PROT
I tried building the recently
released Informix DBD 2005.02 today. I apparently have a successful compile and
link. But I'm having a major problem on the test. Below is the
link input and output, and the first test. All remaining tests look like
the first test. Help and suggestions neede
I believe placeholders (?) could be a better alternative to quote().
Handling of the IN operator was addressed by a thread last October, and
additional information like placeholders which allows for possible prepare
statement optimization. You can jump in on my contribution if you like, and
th
David,
Your solution is similar to mine. But I like your use of the hash slice
better. I keep forgetting about those darn slices.
-Original Message-
From: David [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 21, 2005 6:53 AM
To: dbi-users@perl.org
Subject: Re: inserting data coming f
If I understand your question, it seems like you would want to do:
$sth = $dbh->prepare(q{
insert into tab (date,type,federal,active) values (?,?,?,?); });
Then in a loop:
$dref = $hash{$d}; # $d has "Veterans day" in one iteration
$sth->execute($dref->date,$dref->type,$dref->federal,$dref->a
What people have been saying in this thread is that you should seriously
consider using the placeholder/bind feature of DBI when you insert rows. If
you don't know the feature, learn it in the Perl doc. You'll write less code.
Let me try to explain this simply: when you use this feature, you d
Try something like:
$idx = 17; # or whatever the number of field is you want to change
$data[$idx] = undef if $data[$idx] eq "";
-Original Message-
From: NIPP, SCOTT V (SBCSI) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 16, 2005 9:57 AM
To: CAMPBELL, BRIAN D (BRIAN)
I'm guessing that when a field is empty in your CSV file, then the method
$csv->fields puts an empty string value (e.g. "") in the corresponding element
in your @data array (not an undef value).
If so, you are going to have to detect for this condition and change it to an
undef before binding w
This is a good question. Perhaps a tiny bit off topic for the mailing list but
I'll take a stab at giving you my 2 cents worth, anyway.
Yes, I've done this kind of thing before but only with two or three drivers and
in a different language and using a different data access model (that is, not
FYI,
For some drivers, "rows" may not return the correct value even after all the
rows have been fetched. If I may quote Michael Peppler with regards to Sybase
in an email he sent me. This is in regard to the "rows" method after a call to
fetchall_arrayref...
Relying on $sth->rows() is a lit
s automatically.
3) Added display of row ids for styles that return rows, but not the expected
rows.
4) The script no longer relies on output from the "rows" method, and issues a
warning if it doesn't "work" as expected.
-Original Message-
From: CAMPBELL, BRIAN D
This is more of a Perl question than a DBI question.
The dbh handle is a reference. Therefore, you can pass the reference around,
assign to local variables, assign to object members, etc. and trust that all
your references will all point back to the same connection object.
-Original Mess
Fellow DBI Users,
Tim Bunce has asked me to help revise the NULLs subsection in the "Placeholders
and Bind Values" section in the DBI documention for DBI 1.47. Attached is the
proposed text to be included, along with an associated perl script. You are
invited to review them. Please send comm
Jeffrey,
I don't think the statement below is correct. Did you think that prepare_cached just
remembers the most recently used statement handle?
I believe that prepare_cached retains all prepared statements against the db handle,
not just the last one. So order shouldn't matter.
Your sugges
You need as many "?" as you have entries in your "IN" operator list.
As Niles points out, in your example you had two entries, thus you need 2 "?"s.
Ron Reidy provided this example from Bart Lauer...
> my $SQL = 'SELECT * FROM students WHERE id NOT IN ('
> . join ',' , @ids
>
No, not quite right.
While arrays start from zero, bind_param numbers start at 1.
See my other contribution I posted just prior to this.
-Original Message-
From: Sterin, Ilya (I.) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 14, 2004 8:58 AM
To: Tim Bunce; Martin Moss
Cc: Jenda Kry
Personally, I would recommend this variation of the idiom...
$sth->bind_param($_+1, $execute_args[$_]) for 0..$#execute_args;
Or maybe this???
my $i=1;
$sth->bind_param($i++, $_) foreach @execute_args;
-Original Message-
From: Tim Bunce [mailto:[EMAIL PROTECTED]
Sent: Tuesday, Septembe
-Original Message-
$sth->execute(undef,$data[0],$data[1],$data[2],$data[3],$data[4],$data[5
],$dat
a[6],$data[7],$data[8],$data[9],$data[10],$data[11],$data[12],$data[13],
$data[14
],$data[15],$data[16],$data[17],$data[18],$data[19],$data[20]) or print
"Error with
INSERT _execute_: $DBI
, August 23, 2004 10:14 AM
I found NVL in the March 2003 version of "IBM Informix Guide to SQL:Syntax" page 4-92
-Original Message-----
From: CAMPBELL, BRIAN D (BRIAN) [mailto:[EMAIL PROTECTED]
Sent: Monday, August 23, 2004 12:08 PM
I couldn't find any mention of NVL in my
s expected.
-Original Message-
From: Priest, Darryl - BALTO [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 18, 2004 5:52 AM
To: CAMPBELL, BRIAN D (BRIAN)
Subject: RE: New info on an old Thread: Selecting a record from a table
wh ere a column might be null
Not that it really changes your end sol
I recently encountered some new info to add to an old thread to which I contributed.
Old Thread
Briefly I responded to a query someone made about generalizing WHERE clauses so that
you could use either NULL or non-NULL values to bind to parameterized ?'s. In other
words, you construct a
Technically the question and answer is OT (off topic) because the
difference has to do with Perl quoting features and is not specific to DBI.
However, it does illustrate some techniques that can make the
SQL passed to DBI calls more readable (IMHO) than when you use conventional quotes (""
or '').
Nikolay,
So it sounds like you were hit the same free memory issue.
Regarding the tests, were they t51, and t58? I find that they don't run successfully
when when run with the entire test suite, but they do run OK when run individually.
So I attributed that to a test plan problem, not a DBD pro
I built DBD::Informix on Win32 last fall. There was a lot of stuff I had to change to
get it to compile under Win32, and it's all documented in this posting.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg19771.html
Your problem below looks like it might be the free memory problem I ran into.
atement handles that a database handle can
have? How much memory will each one use and do you have enough memory?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 06, 2004 9:26 AM
To: CAMPBELL, BRIAN D (BRIAN)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
I posted this solution originally.
Please be aware that this solution does require a "prepare" for each execute. So if
you are running this logic in a loop many times, the run time will be more expensive
than other methods that were posted. You can monitor the performance of your app and
see i
her.
-Original Message-
From: Reidy, Ron [mailto:[EMAIL PROTECTED]
Sent: Friday, April 30, 2004 1:18 PM
To: CAMPBELL, BRIAN D (BRIAN); [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Selecting a record froma table where a column might be null
The OP's problem was specific to Oracle a
The problem as I understand it is that the snippet of code below could be executed,
where $pro_pr_branch variable could have "undefined" which would signify a NULL
database "value".
I which case an "IS NULL" query is desired.
I saw solutions using NVL(), ISNULL(), etc. which appear to be databas
Just out of curiousity, how does DBI->err() even work?
Did the DBI module export an object referece called "DBI" which in
turn calls the class method DBI::err?
Sorry, DBI.pm is not handy right now, from my current "email venue" so I
can't look at the code for myself today.
-Original Message-
56 matches
Mail list logo
