On 11/07/11 3:30 PM, Edson Richter wrote:
Thanks for the fast answer. Is there any way to avoid that? I mean, in
MS SQL Server, I do have "with no_lock" (that produces dirty reads)?
Or the way to go is the transaction isolation level?
there's no actual overhead in a single statement read trans
On Mon, Nov 7, 2011 at 3:30 PM, Edson Richter wrote:
> Thanks for the fast answer. Is there any way to avoid that? I mean, in MS
> SQL Server, I do have "with no_lock" (that produces dirty reads)?
> Or the way to go is the transaction isolation level?
The lowest level of Isolation supported by Po
Em 07-11-2011 20:54, John R Pierce escreveu:
On 11/07/11 2:41 PM, Edson Richter wrote:
Does simple SELECT query like
select * from tableX
(without FOR UPDATE) opens an implicit transaction when issued?
opens and closes.if you don't bracket with BEGIN;
COMMIT|ROLLBACK;then ea
On 11/07/11 2:41 PM, Edson Richter wrote:
Does simple SELECT query like
select * from tableX
(without FOR UPDATE) opens an implicit transaction when issued?
opens and closes.if you don't bracket with BEGIN;
COMMIT|ROLLBACK;then each statement is a transaction of and by itself
On Wed, 12 Nov 2003, Rick Gigger wrote:
> Is this correct?
>
> vacuum by itself just cleans out the old extraneous tuples so that they
> aren't in the way anymore
> vacuum analyze rebuilds indexes. If you add an index to a table it won't be
> used until you vacuum analyze it
> vacuum full actual
> > Is this correct?
> >
> > vacuum by itself just cleans out the old extraneous tuples so that they
> > aren't in the way anymore
>
> Actually it puts the free space in each page on a list (the free space
> map) so it can be reused for new tuples without having to allocate
> fresh pages. It finds
Is this correct?
vacuum by itself just cleans out the old extraneous tuples so that they
aren't in the way anymore
vacuum analyze rebuilds indexes. If you add an index to a table it won't be
used until you vacuum analyze it
vacuum full actually compresses the table on disk by reclaiming the space
On Monday 21 May 2001 01:27, Johnny_ wrote:
> I want to use an aggregate function in the WHERE clause and SQL Server 7
> won't let me? Specifically, I need to find a customer ID where the budget
> is equal to MAX(budget). Is my logic wrong? How can I display the the
> customer ID with the b
At 03:43 PM 12/11/2000 +, [EMAIL PROTECTED] wrote:
>As an aside in DB2 there is the concept of a shared weight index which
>depending
>on
>locale lumps lower/upper case characters together so that you don't have to
>include
>an UPPER in the SQL - and it will use the index. Perhaps postgres c
Tomas Berndtsson <[EMAIL PROTECTED]> writes:
> Related to this, is there any way to make an index for a table
> case-insensitive? If you have an index, but use upper() in the select,
> the index is not used.
Sure, make a functional index:
play=> create table foo (f1 text);
CREATE
play=> create i
"Hancock, David (DHANCOCK)" <[EMAIL PROTECTED]> writes:
> Abe: It's an SQL thing or a scripting thing. It's probably easiest and
> safest in the SQL:
>
>select firstname, surname from employees
> where upper(firstname) like upper('%$criteria%') or
> upper(surname) like upper('%$
On Sunday 10 December 2000 07:23, Abe wrote:
> This is probably an easy question for most but here goes:
>
> I am using PHP3 and postgres 6.5
>
> I am trying to do a search on a peoples database and it works fine except
> for the fact that I want to make it case insensitive as some in the
> databa
Abe: It's an SQL thing or a scripting thing. It's probably easiest and
safest in the SQL:
select firstname, surname from employees
where upper(firstname) like upper('%$criteria%') or
upper(surname) like upper('%$criteria%')
That is, force the column and the search string to upper
Thanks David,
works a treat!
Abe
- Original Message -
From: "Hancock, David (DHANCOCK)" <[EMAIL PROTECTED]>
To: "'Abe '" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, December 10, 2000 12:48 PM
Subject: RE: [GENERAL] Simple Quest
14 matches
Mail list logo
