Am 12.11.2007 um 14:40 schrieb Igor Tandetnik:
There is no syntax in SQLite to create a view (or anything else)
with name generated at runtime from field values. A view name is a
plain identifier hardcoded into the statement - it is not evaluated
as an expression.
great, thx for this quick clarification.
What you can try is call a custom function from the trigger (see
sqlite3_create_function), which function can then create a view.
The function can use string manipulation to generate an appropriate
SQL statement from the values of its parameters.
ok, maybe later - something tells me maybe simple SELECTS within my
app could do it, too.
I wonder - do you have any plans to eventually drop some of these
views? Or are you just going to keep creating them, exploding the
size of the database schema? In fact, why on earth do you need so
many views in the first place?
hmm, honestly i planned a ON DELETE-Trigger as soon as the ON INSERT-
Trigger works ;-) to sum it up : i expect to gather 25-30 rows in the
config-table and ~200-250 corresponding rows in the files table. That
makes at worst 7500 rows in the files-table. That said, i see myself
far away from performance-issues. My question belongs to the area
'research-while-developing' or maybe howto place as much logic into
the DB, not polluting my apps-source lines with SELECT-staements. I'm
used to do things dynamically and usually use OODB's with python. For
this tiny project it's JS and sqlite and things work different here -
but it's gone work.
@Joe :
welcome to hackland ;) i've seen that approach in threads about
'cascading | recursive'-triggers on this list and assumed a solution
to my tiny prob. thx for the example, i'll keep it till the next
rainy sunday-afternoon comes - i'm sure i'll find a way to make the
main-schema explode somehow ;-)
greets, andreas
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
