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 ex
You were using the outside table alias in the subquery:
SELECT * FROM tblZO_Haupt AS hpt
WHERE hpt.datum = (
SELECT MAX(hpt_sub.datum)
FROM tblZO_Haupt AS hpt_sub
WHERE hpt_sub.zo_tblSaenger = hpt.zo_tblSaenger
AND hpt_SUB.zo_tblEnsemble = 1
AND hpt_SUB.zo_tblStueck = 1
AND h
I clearly am not in the right mindset to be answering list emails.
Please ignore my response (it's too late now)--back to my stressful
deadline.
Strange that it's implemented for prefix and not postfix?
Wes
On Wed, Aug 5, 2009 at 8:58 PM, Lukas Haase wrote:
> Wes Freeman schrie
Why not LIKE '%otor'?
Wes
On Wed, Aug 5, 2009 at 7:47 PM, Lukas Haase wrote:
> Hi,
>
> It's me again, sorry. The next big problem concerning FTS. I have the
> requirement to do postfix searches, like:
>
> SELECT topic_title FROM topics
> WHERE topic MATCH '*otor'
> ORDER BY topic_title ASC;
>
> s
It's possible that the question was referring to this statement in the
About page on sqlite.org:
"SQLite is an embedded SQL database engine. Unlike most other SQL
databases, SQLite does not have a separate server process. SQLite
reads and writes directly to ordinary disk files. A complete SQL
datab
Yeah, sorry about that. In two statements:
select max(number) from table where number < ?
select min(number) from table where number > ?
if you want to merge them into a single statement, you can do:
select (select max(number) from table where number < ?)
highest_smaller, (select min(number) from
Sorry, I misread the question...
Still, I think min/max are better than order by limit 1.
Wes
On Mon, Jul 13, 2009 at 7:24 PM, Wes Freeman wrote:
> Select max(number), min(number) from table;
>
> Wes
>
> On Mon, Jul 13, 2009 at 7:16 PM, Bogdan Nicula wrote:
>>
>>
>
Select max(number), min(number) from table;
Wes
On Mon, Jul 13, 2009 at 7:16 PM, Bogdan Nicula wrote:
>
>
> Hi,
>
> Sorry for my lack of SQL knowledge which triggered this help request:
> Given a column containing numbers, which is the most efficient manner to find
> out the highest smaller and
This will create another table TmpTable (tax, direction), using the
values from the table MarketTable:
create table TmpTable as
select tax,
(select
case when b.tax < MarketTable .tax
then "Up"
when b.tax>=MarketTable .tax
then "Down"
else null
end
from MarketTable b
where b.row
If you want to use the rowid to order the rows (or an
auto-incrementing primary key field), you could do something like
this:
update tst
set Direction=
(select
case when b.tax < tst.tax then "Up"
when b.tax>=tst.tax then "Down"
else null
end
from tst b
where b.rowid=tst.rowid-1)
Wes
VACUUM cleaned up the file in my current test, after 1200 iterations,
making it run at ~4.6seconds again, rather than ~5.1. It seemed to get
it almost back to the performance of a clean file.
Didn't know about the vacuum command--Cool. By the way, the vacuum
operation takes ~1.6 seconds for my tes
On Tue, Jun 16, 2009 at 2:51 PM, Jens Páll
Hafsteinsson wrote:
> Closing and opening again did not speed up steps 1-4, it actually slowed
> things down even more. The curve from the beginning is a bit similar to a
> slightly flattened log curve. When I closed the database and started the test
>
I also wrote my own test in a small Qt/C++ app.
First I tried on my 10k rpm U160 SCSI drive, and it stayed roughly
between ~23 seconds per set (one set is 100 of: start
transaction->insert 1000->commit, as described). I let it run for
about 10 minutes before stopping it. It's hard drive bound on t
13 matches
Mail list logo
