Igor Tandetnik wrote:
> Baruch Burstein wrote:
>> Does sqlite not support table aliases in update statements?
>
> Indeed it does not.
>
>> Is there a way
>> to work around this to get the affect of
>>
>> update table1 t1
>>set col1 = col1 * 2
>>where col1 <=
On 1 Apr 2012, at 2:24pm, Igor Tandetnik wrote:
> Simon Slavin wrote:
>> On 1 Apr 2012, at 2:09pm, Baruch Burstein wrote:
>>
>>> update table1 t1
>>> set col1 = col1 * 2
>>> where col1 <= (select avg(col1)
>>>
On Apr 1, 2012, at 3:21 PM, Simon Slavin wrote:
> Can this be done with a JOIN instead of a sub-SELECT ?
Not in SQLite, as the join clause is not supported in an update statement.
For such functionality, look at MySQL or Postgress which do support variation
of such syntax.
Something like
Simon Slavin wrote:
> On 1 Apr 2012, at 2:09pm, Baruch Burstein wrote:
>
>> Does sqlite not support table aliases in update statements? Is there a way
>> to work around this to get the affect of
>>
>> update table1 t1
>>
>>set col1 = col1 * 2
>>
On 1 Apr 2012, at 2:09pm, Baruch Burstein wrote:
> Does sqlite not support table aliases in update statements? Is there a way
> to work around this to get the affect of
>
> update table1 t1
>
>set col1 = col1 * 2
>
>where col1 <= (select avg(col1)
>
>
Baruch Burstein wrote:
> Does sqlite not support table aliases in update statements?
Indeed it does not.
> Is there a way
> to work around this to get the affect of
>
> update table1 t1
>set col1 = col1 * 2
>where col1 <= (select avg(col1)
>
On Apr 1, 2012, at 3:09 PM, Baruch Burstein wrote:
> Does sqlite not support table aliases in update statements?
Nope, no aliasing in the update itself.
> Is there a way
> to work around this to get the affect of
>
> update table1 t1
>
>set col1 = col1 * 2
>
>where col1 <= (select
Does sqlite not support table aliases in update statements? Is there a way
to work around this to get the affect of
update table1 t1
set col1 = col1 * 2
where col1 <= (select avg(col1)
from table1
where col2=t1.col2);
--
Programming today is
I agree with Tom. With the proper indexes a single table for all
languages is the way to go.
I don't think a view for each language is necessary--just make a
function that takes language and whatever you use to look up the
localized strings, and returns the localized string.
Further, there are
Hi Shaun,
> It'd be extremely useful if I were able to alias a table as
> "CurrentLanguage" as opposed to directly referencing the actual
> name. This saves me from having to tweak my lookup statements on
> the fly to change the table name being accessed. Is it possible to
> perform
Hi,
yes, creating a table will duplicate your data. However, a view will not:
create view CurrentLanguage as select * from SomeLanguage;
see http://www.sqlite.org/lang_createview.html
Martin
Shaun Seckman (Firaxis) wrote:
> Happy Friday everyone!
>
> I've got several tables
Happy Friday everyone!
I've got several tables each representing a specific
language which my application uses to access translated strings. It'd
be extremely useful if I were able to alias a table as "CurrentLanguage"
as opposed to directly referencing the actual name. This
12 matches
Mail list logo