At 11:05 AM -0700 7/26/05, Drozdowski, Catharine wrote:
Hi Folks,
First of all, I want to second the database independence comment. As an
Oracle DBA who has watched application vendors try to create
applications which "run on all databases" I have seen anything from an
ISAM format kludged into a
Remember we are posting to a "Database Independent"
mailing list. So such talk is likely to get you
banned for life. :)
Lots has been written about this over the years and
there isn't much point in hashing it out here again.
Tom Kyte, and Jonathan Lewis all have weighed in on
this in publishe
Hi Folks,
First of all, I want to second the database independence comment. As an
Oracle DBA who has watched application vendors try to create
applications which "run on all databases" I have seen anything from an
ISAM format kludged into a relational model which ran slower than a dead
dog no matte
list tables or metadata queries usually go against
all_tables and all_tab_columns.
The method typically passes in a schema owner and a
table name. I have traced the equivalent jdbc method
before and there is usually a placeholder for the
schema owner so that you can make it equivalent to
user_t
On Tue, 2005-07-26 at 10:45 -0600, Reidy, Ron wrote:
> What takes so long for you? What query is being executed and what are the DB
> waits generated? Are you getting SYS owned objects as described in that old
> posting?
>
Yes indeed I am getting SYS owned objects as described in the old
post
What takes so long for you? What query is being executed and what are the DB
waits generated? Are you getting SYS owned objects as described in that old
posting?
-
Ron Reidy
Lead DBA
Array BioPharma, Inc.
-Original Message-
From: Tielman de Villiers [mailto:[EMAIL PRO
I have the same problem as described here:
http://www.nntp.perl.org/group/perl.dbi.users/7343
(searching from Oracle databases take extremely long because
DBIx::Recordset tries to get metadata for all tables), even though
I use modern versions of DBIX::Recordset (0.26), the
DBI(1.40) and perl (5.8
I think you are partially correct in the updating code comment but I
believe another reason is that we have stored procedures that use
SQL_VARIANT as the attribute type - which is not defined in the
sqltypes.h file. If my memory serves me correctly we were having
problems with that...I'd have to d
On 26-Jul-2005 Brian Becker wrote:
> Ok this works...but just to be a large pain in the ass...
hmm.
> If I change my connection slightly to use odbc_default_bind_type=12 then
> the problem still exists where I get 0 records instead of the 5
> expected. This may be incorrect to do on so many lev
The current versions of both will work nicely.
Both are found on CPAN.
All details that are normally necessary are found in the fine
documentation that is bundled with the source code.
Further details may be found at http://google.com.
Jared
On Sun, 2005-07-24 at 23:42, Ata Raja wrote:
> Hi,
>
Ok this works...but just to be a large pain in the ass...
If I change my connection slightly to use odbc_default_bind_type=12 then
the problem still exists where I get 0 records instead of the 5
expected. This may be incorrect to do on so many levels that are beyond
my understanding, but that's w
Brian,
Sorry about that. I should have run through the tests.
In:
rgbValue = NULL;
phs->cbValue = SQL_NULL_DATA;
+ cbColDef = phs->cbColDef;
the last line needs to be:
if (phs->cbColDef) cbColDef = phs->cbColDef;
This should not now make it any worse tha
Was this supposed to happen? A large # of tests now fail...
t/07bind.ok 1/11Can't rebind placeholder 3 at t/ODBCTEST.pm line
228.
# Looks like you planned 11 tests but only ran 2.
# Looks like your test died just after 2.
t/07bind.dubious
Test returned status 255 (wstat 652
Brian,
OK, I've found this now. It is rather more complicated that it looks.
I did this in odbctest (directly to MS SQL Server driver):
create table mjenull(a varchar(20))
insert into table values ('AAA')
select * from table where a = isnull(NULL, 'AAA')
correctly returns 1 row.
now:
SQLPrepar
[EMAIL PROTECTED] (Jeff Zucker) writes:
> Radomir Hejl wrote:
>
>>Hello,
>>does DBD::CSV supports the following select clause?
>>
>>select * from table where upper (col1) like '%ab%';
>>
>>
> Yes that syntax is supported, although, I think you might want LOWER
> (col1) instead of UPPER since the e
Brian,
Looks like the NULL is getting to the SQL Server
ODBC driver to me - see below.
Brian Becker wrote:
Yes I am referring to the ODBC-ODBC Bridge.
Here is the esoobclient.log
SQLBindParameter(2bfd88,1,1(Input::),1,12,1,0,0,0,2c17e8)
^oobc_expand_desc_recs(2bfe98,1)
Exp
16 matches
Mail list logo
