andrew wrote:
Barbara Duprey wrote:
andrew wrote:
Hi,
I took the liberty of adding a page to the Base area of the wiki.
http://wiki.services.openoffice.org/wiki/Built-in_functions_and_Stored_Procedures
Also updated the spreadsheet, available at my ftp server.
The function TRIM is now grouped with string functions, and I added
the statistical functions ( STDDEV_POP, STDDEV_SAMP, VAR_POP,
VAR_SAMP ).
It could use some explanations and examples perhaps.
Drew
When I looked at the article, it seemed to be missing the "TRIM ( ["
-- it started right off with LEADING, and had an extra | after BOTH.
It's also a bit confusing that LTRIM and RTRIM (and a number of other
functions) refer to s, while TRIM refers to <COLUMN>, with all of
them apparently wanting the name of a text field, enclosed in double
quotes if the field name is not all uppercase. How about
TRIM([LEADING | TRAILING | BOTH] FROM s)
thanks for catching that
The table cells for "Desinger" [sic], Parser, and Direct are not
filled in for the statistical functions. And I do think a little
explanation about context might be needed for those; I'm still not
altogether clear about how these columns relate to the possible
contexts for issuing SQL commands. Here's a stab at what I think
might be a useful preliminary statement (though I may well be
misunderstanding this, I'm barely a beginner here!)
Haven't tested each yet to see if they run in the designer..or however
I seem to want to spell it. I believe they will, but want to try first.
SQL commands can be issued (a) using the Tools | SQL option of the
main Base window, or (b) from the Query Designer in Design view,
using the Edit | Run Query option, or (c) from the Query Designer in
SQL view, using the Edit | Run SQL command directly option, or the
equivalent toolbar icon. The Query Designer is only intended for
commands that prepare a result set of data for viewing or editing
(i.e., for SELECT commands). For commands in one of these contexts,
the tables below indicate which functions can be included in the
command. Designer indicates context b; Parser indicates context a;
and Direct indicates context c.
A good start there. I would change a couple of things. Some of this,
though not the list of functions, is covered in the Base Chapter of
the Getting Started Guide already. But the page here needs to have
something - I know.
Maybe a change to something like this.
----------------------
The TOOLS > SQL window allows any valid SQL statement to be run, but
it does not return any results to the user. So the main purpose is to
issue Data Definition Language ( DDL ) commands. i.e. CREATE TABLE,
ALTER TABLE.
A secondary use is to issue Data Manipulation Language ( DML )
commands. i.e. UPDATE, DELETE, INSERT commands
The Query component in Base allows for SQL commands that return a
result set. i.e. SELECT and CALL
The Query component in Base supports a GUI query designer, and a text
based query editor.
The Query component in Base also supports the use of named replaceable
parameters in these statements, in most cases.
This feature is controlled by the option 'Escape Processing'.
Escape Processing is always set to TRUE when using the GUI query
designer.
Escape Processing is on by default in the text based query editor, but
may be turned off by selecting the 'Run SQL directly' tool button.
In the tables below each function is marked as being available or not
in these three modes of the query component.
Yes in the Designer column means that it may be used in the GUI query
designer.
Yes in the Parser column means that it may be used in the text base
query editor with escape processing enabled.
No in the Parser column mens that the function is only available in
the text based query editor with escape processing disabled.
-------------------------
( which means I have one to many columns there )
It would make sens to change that third column then to 'Comments' and
give a brief explanation of what the function does and any options is
supports.
Ah! Very nice. A little inconsistency between SQL statement and SQL
command, and TRUE/on for escape processing. And I'd tend to call the
text based query editor the SQL View editor (or SQL View text editor),
for a little better tie-in to the GUI's Create Query in SQL View task
and Query Designer's View > Switch Design View On/Off. And while we're
at it, maybe a Design View graphical query designer, rather than GUI
query designer (after all, we're in some kind of GUI for all of this -
no command line interface).
The Comments column would be wonderful!
(You can probably tell I've spent a lot of time being an editor! Picky,
picky! I'd be glad to help you on this, if you'd like, or just shut up
about all this petty stuff.)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
