Use the SELECT INTO statement to retrieve a single
row from a table. The PSQL select
statement is identical to the SQL select statement followed by an
INTO clause and a semicolon.
<select_stmt> INTO <var_list>
<variable_name> , <var_list>
A SQL insert
statement as defined in the SQL Reference manual.
The name of a local
variable of the enclosing body or of a parameter of the
enclosing procedure definition.
See the SQL Reference Manual for a description of
the select statement.
The select statement must return exactly one row.
If it returns zero or more than one row, a run-time error occurs.
The below is an example of a valid INSERT
statement in PSQL:
SELECT COUNT(*) FROM
rdb$relations INTO :table_count
DELETE, UPDATE and INSERT
|Contributed by CAhswhJktFMtQKu on 1 June 2008 09:46 AM|
|Contributed by unordained on 17 February 2009 05:27 PM|
This page seems wrong to me:
- If the select returns more than one row, sql message -811 (engine code 335544652) is raised.
- If the select returns one row, the variables are updated appropriately.
- If the select returns zero rows, the variables are left as-is. No exception is thrown. SQL Code 100 (no data found) does not seem to show up on empty selects. (Neither of this form, nor of the \"for select ... into ... do\" form.)
This is not true of singleton selects as sub-queries though: select ... where fieldname = (select ...); In this case, the sub-query must return exactly one row (and one column). An empty sub-query is not treated as \"null\". A runtime exception is raised.
Also, why does it say \"a valid insert statement\" for something that\'s just a select?
|Contributed by Lovely on 3 September 2012 03:08 AM|
Denny,There IS a bug in the incrementing of the major verosin. I\'ve fixed it in SVN, but haven\'t made a new public release with the fix (one more entry on my list of things to do \"sometime\"). Since the major verosin only updates between migrations, the bug can only manifest itself if there is an issue with the first step of a given migration, but you\'re right, there is an issue there. The minor verosins (steps within a migration) are double protected: the increment happens second, and the whole thing is wrapped in a CFTRANSACTION. The reason the major verosin increments first is for internal bookkeeping reasons. It\'s safe for it to increment even if the first migration step fails, because it\'ll be minor verosin zero (which means the first step is still next in line). The bug was in when the minor verosin was reset to zero; it happened at the wrong time before.For the two-developer conflict scenario, there\'s nothing the tool can do about it. You have to resolve the conflicts when the second developer commits his/her changes. Migration code does have some ordering ramifications, so resolving a conflict might not be as simple as otherwise (quite possibly requiring manual tweaks to the `schema_verosin` table), but it\'s really no different from any other conflict between multiple developers.
|Contributed by cheap backlinks on 18 July 2014 07:13 PM|
O6Hksg I cannot thank you enough for the article.Thanks Again. Really Great.
|Contributed by crorkz on 16 January 2015 01:19 AM|
MwSG14 Thank you, I\'ve recently been looking for info about this topic for ages and yours is the greatest I\'ve discovered so far. But, what about the conclusion? Are you sure about the source?
Extend this topic - Post a comment