On Tue, Dec 6, 2011 at 5:54 AM, Jens Rehsack wrote:
> 2011/12/2 Brendan Byrd :
> >
> > Well, as long as it's reflected as a schema all throughout, that's fine.
> > However, I'm not convinced that it's not going to strip out the schema
> from
> > the SQL, unless DBD::Sys is overloading the affecte
2011/12/2 Brendan Byrd :
> On Thu, Dec 1, 2011 at 1:27 AM, Jens Rehsack wrote:
>>
>> > On Wed, Nov 30, 2011 at 4:14 AM, Jens Rehsack
>> > wrote:
>> > But, we still need an outlet to put these things in. I keep hearing
>> > about a
>> I see no reason to do this _now_. Nothing you desire needs S::
On Thu, Dec 1, 2011 at 1:27 AM, Jens Rehsack wrote:
> > On Wed, Nov 30, 2011 at 4:14 AM, Jens Rehsack
> > wrote:
>
> > But, we still need an outlet to put these things in. I keep hearing
> about a
> I see no reason to do this _now_. Nothing you desire needs S::S changes,
> only the way you de
fer from S::S::E to DBI::DBD::SE.
Don't cramp at S::S - DBI makes the rules! So DBI::DBD::SqlEngine
and subsequent docs must be read.
>> > If we correct it to enforce proper
>> > ODBC case-sensitivity, that may suddenly break the DBD and users of
>> > those
>&g
).
The storage backend might need to do it's own correction, as DBD::File
does.
> Should we worry about it or not?
Well, I don't worry about this for SQL::Statement 1.xxx.
> If we correct it to enforce proper
> ODBC case-sensitivity, that may suddenly break the DBD and users of
};
So, it's deliberately grabbing the untouched (pre-corrected) table name
from org_table_names and passing it to open_table. What's the reasoning
behind this? Should we worry about it or not? If we correct it to enforce
proper ODBC case-sensitivity, that may suddenly break the D
On Mon, Jun 29, 2009 at 10:08 AM, David Fetter wrote:
> On Mon, Jun 29, 2009 at 09:54:04AM -0700, Jonathan Leffler wrote:
> > On Mon, Jun 29, 2009 at 9:23 AM, David Fetter wrote:
> >
> > > On Mon, Jun 29, 2009 at 04:26:30PM +0100, Tim Bunce wrote:
> > > > Oracle is one of those databases that up
On Mon, 29 Jun 2009 10:08:32 -0700, David Fetter
wrote:
> On Mon, Jun 29, 2009 at 09:54:04AM -0700, Jonathan Leffler wrote:
> > On Mon, Jun 29, 2009 at 9:23 AM, David Fetter wrote:
> >
> > > On Mon, Jun 29, 2009 at 04:26:30PM +0100, Tim Bunce wrote:
> > > > Oracle is one of those databases that
On Mon, Jun 29, 2009 at 09:54:04AM -0700, Jonathan Leffler wrote:
> On Mon, Jun 29, 2009 at 9:23 AM, David Fetter wrote:
>
> > On Mon, Jun 29, 2009 at 04:26:30PM +0100, Tim Bunce wrote:
> > > Oracle is one of those databases that uppercases (unquoted)
> > > names. That's perfectly valid behaviou
On Mon, Jun 29, 2009 at 9:23 AM, David Fetter wrote:
> On Mon, Jun 29, 2009 at 04:26:30PM +0100, Tim Bunce wrote:
> > Oracle is one of those databases that uppercases (unquoted) names.
> > That's perfectly valid behaviour - though it can be a major pain.
>
> It's not just valid behavior. It's ma
On Mon, Jun 29, 2009 at 04:26:30PM +0100, Tim Bunce wrote:
> Oracle is one of those databases that uppercases (unquoted) names.
> That's perfectly valid behaviour - though it can be a major pain.
It's not just valid behavior. It's mandated by the SQL standard :(
Cheers,
David.
--
David Fetter
I found out last week that MySQL is even worse, as it prohibits the
use
of a space before a paren in aggregate functions. But that is not on
topic here.
True, though I believe there's a config option to control that
(a trade-off with some other feature that I don't now recall).
IGNORE_SPA
On Mon, 29 Jun 2009 16:26:30 +0100, Tim Bunce
wrote:
> On Mon, Jun 29, 2009 at 04:06:23PM +0200, H.Merijn Brand wrote:
> > No database is perfect, but Oracle keeps causing massive hate
> >
> > $ cat test.pl
> > #!/pro/bin/perl
> >
> > use strict;
> > use warnings;
> >
> > use DBI;
> > use Data
On Mon, Jun 29, 2009 at 04:06:23PM +0200, H.Merijn Brand wrote:
> No database is perfect, but Oracle keeps causing massive hate
>
> $ cat test.pl
> #!/pro/bin/perl
>
> use strict;
> use warnings;
>
> use DBI;
> use Data::Peek;
>
> my $dbh = DBI->connect ("dbi:Oracle:", (split m{/} => $ENV{DBUSE
No database is perfect, but Oracle keeps causing massive hate
$ cat test.pl
#!/pro/bin/perl
use strict;
use warnings;
use DBI;
use Data::Peek;
my $dbh = DBI->connect ("dbi:Oracle:", (split m{/} => $ENV{DBUSER}), {
AutoCommit => 1,
RaiseError => 1,
PrintError
H.Merijn Brand wrote on 05/09/09 10:10:
Can someone show me the case specifications for SQL?
I think that unless quoted table names are case insensitive, so
SELECT * FROM FOO;
equals
select * from foo;
but does not equal
SELECT * from "Foo";
What you describe matches DB2 and Oracle
On Sat, 09 May 2009 08:22:19 -0700, jeff wrote:
> The standard is case-insensitive for undelimited identifiers. The
> problem with DBD::File is that some operating systems are case sensitive
> when it comes to file names so if there is a one-to-one table/file
> correspondance, there can be pr
On Sat, May 9, 2009 at 7:10 AM, H.Merijn Brand wrote:
> Can someone show me the case specifications for SQL?
> I think that unless quoted table names are case insensitive, so
>
> SELECT * FROM FOO;
>
> equals
>
> select * from foo;
>
> but does not equal
>
> SELECT * from "Foo";
>
> IMHO, when
The standard is case-insensitive for undelimited identifiers. The
problem with DBD::File is that some operating systems are case sensitive
when it comes to file names so if there is a one-to-one table/file
correspondance, there can be problems.
--
Jeff
H.Merijn Brand wrote:
Can someone show
know about the standard - but Sybase (and MS-SQL probably) is
case-sensitive by default, though that can be changed with the "sort-
order" configuration of the server.
The case-sensitivity (or not, if a case-insensitive sort order is
used) is valid both for table names/object names, a
Can someone show me the case specifications for SQL?
I think that unless quoted table names are case insensitive, so
SELECT * FROM FOO;
equals
select * from foo;
but does not equal
SELECT * from "Foo";
IMHO, when selecting from files, unquoted table names should match
case-insensitive
On Thu, 20 Feb 2003 14:44:02 -0500
"Jose Blanco" <[EMAIL PROTECTED]> wrote:
> Any ideas why SQL statements like this one:
>
> SELECT collid FROM Collection where collid= '123' and (userid = 'JoseA' or
> userid = 'JoseB')
>
> Are not working with SQL::Statement version 1.005, but are with version
- Original Message -
From: "Francois Desarmenien" <[EMAIL PROTECTED]>
To: "Jose Blanco" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, February 20, 2003 3:29 PM
Subject: Re: case sensitivity when creating a t
,
Jose
- Original Message -
From: "Jeff Zucker" <[EMAIL PROTECTED]>
To: "Jose Blanco" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, February 19, 2003 4:55 PM
Subject: Re: case sensitivity when creating a table.
> Jose Blanco wr
Jose Blanco wrote:
I just installed SQL::Statement version 1.005 and using a CSV database I tried creating a table with field names that were in lower case. The table that got created had the field names in upper case.
Version 1.006 will be out in the next day or so and it will solve this
pro
I just installed SQL::Statement version 1.005 and using a CSV database I tried
creating a table with field names that were in lower case. The table that got created
had the field names in upper case.
Before this I was using SQL::Statement version 0.1020 and I was able to create the
table with
26 matches
Mail list logo
