i have the following code :
SELECT *
FROM tbl_doc
/*_archive*/
,
TBL_LOG#dblink
WHERE Prim_id='2121212';
What is /*_archive*/ mean ?
in my database we have :
tbl_doc_status
tbl_doc_archive
tbl_doc_save
From a /* sequence to the following */ sequence, as in the C programming language. This syntax enables a comment to extend over multiple lines because the beginning and closing sequences need not be on the same line.
MySQL Server supports certain variants of C-style comments. These enable you to write code that includes MySQL extensions, but is still portable, by using comments of the following form:
/*! MySQL-specific code */
Related
I do have some problems to define an Alias definition in doxygen when I have to use multiple commands in the alias definition.
What I am trying to achieve is actually the output of sample DD_32 below.
I currently don't know why the output of #DD{22, Test Description} looks different. Also tried to provide escaped quotes to the ALIAS definition, but still. No luck.
My alias definition is as follows:
ALIASES += DD{2}="\page DD_\1 \"Design \1\" \brief \2 #par Implementation:"
For testing I use the following code:
/**
* #page DD_31 Design 31
* #brief Descrition
* #par Implementation:
*/
/**
* #DD{22, Test Description}
*/
I would suspect, that the output is identical, but it looks like in the screenshot provided below:
As you can see, the \brief description is actually part of the page name.
Any hints how I could fix this issue?
Thanks a lot.
For completeness;
As proposed in the comments by albert, his pull request implements physical newlines in an alias by placing ^^ in between separate commands.
So, for example:
ALIASES += DD{2}="#page DD_\1 "Design \1" \brief \2 ^^ #par Implementation:"
i have the following delphi code:
FDQuery1.SQL.Clear;
FDQuery1.SQL.Add('SELECT * FROM :Tablename');
FDQuery1.ParamByName('Tablename').AsString := 'tasks';
ShowMessage(FDQuery1.sql.Text);
FDQuery1.Open;
(coppied from this link: http://www.delphigroups.info/2/da/237634.html)
it does not work because the parameter is not filled but stays the same.
does somebody know why it is not filled?
Because you cannot use parameters for table name substitution in SQL commands in general. You are lucky enough here though, FireDAC supports preprocessor macros to parametrize table names in SQL commands. So you can write for example this (note that if you want to see the command as you did in your code, it must be after macro preprocessing, that is e.g. after calling Prepare):
FDQuery1.SQL.Text := 'SELECT * FROM &TableName';
FDQuery1.MacroByName('TableName').AsIdentifier := 'tasks';
FDQuery1.Open;
For details about this kind of macros, see the substitution variables topic.
The heading at the start of the comment block shown in the C code below is formatted incorrectly in both HTML and PDF output as \verbatim text.
All other Doxygen comments I have in this file work perfectly (they are all VERY similar as the file provides functions that conform to a type).
I have tried removing all preceding Doxygen comments from the file (except the #name) to rule out incorrect block formatting closing, removing the heading spec (#'s) changing the heading text (eg "foo") in case of incorrect characters, removing the later \verbatim block, removing this entire comment block itself to see if the problem transferred to the next one, but nothing seems to change!!
How can I get the heading to format correctly?? Thanks.
code:
/** # *IDN? - Identification query #
* This query allows the instrument to identify itself. It responds with a `<`string`>` consisting of four fields
* separated by commas. The four fields are determined by constants defined in the application
* specific settings in config.h and appear in the following order:
* \verbatim MANUF,MODEL,SERIAL,FIRMW \endverbatim
* See the config.h file description for information on each of these fields.
*
* #param parameters None
* #param query `*IDN?`
*/
extern int16_t IDN (double * parameters, bool query);
How this looks in PDF:
How this looks in HTML:
EDIT: The comments for the OPC function:
/** # *OPC - Operation Complete Command. #
* This command causes the device to set the operation complete bit in the standard event status register when
* all pending device operations have completed.
*
* The query responds with an ASCII "1" when all pending device operations are complete.
*
* #param parameters None
* #param query `*OPC?`
*/
extern int16_t OPC (double * parameters, bool query);
Finally solved this, though Im still unsure as to the cause.
Basically I rewrote the documentation comment a bit at a time (I was trying to see if I could isolate any one item that caused it).
I started with a one word comment, when that appeared correctly I slowly added more bits, rebuilding after each addition. I now have the full comment, exactly as before, but now working as intended
Puzzling... maybe doxygen only rebuilt that part after it detected the comment being deleted and started again and that cleared whatever the issue was?? Meh, it's fixed anyway. Thanks for the suggestions.
with
#!/usr/bin/perl
use warnings;
use strict;
use 5.010;
use SQL::Parser;
my $parser = SQL::Parser->new( 'ANSI', {RaiseError=>1} );
my $word = 'BETWEEN';
my $success = $parser->feature( 'reserved_words', $word );
$success = $success ? '' : 'NOT';
say "$word is $success a reserved word";
I can check if a word is a reserved word.
Is there a function that gives me a list of all reserved words?
SQL::Dialects::ANSI is a simple interface to information about ANSI SQL in INI format. So you get that and parse it... except its not in INI format because it doesn't contain key = value but just key which chokes Config::INI. Alas, this is one of the few INI parsers I could find that will deal with a string.
So you might have to parse it by hand. That's what SQL::Parser does.
Alternatively you can pull the list out of SQL::Parser's guts.
use Data::Dumper;
use SQL::Parser;
my $s = SQL::Parser->new;
print Dumper $s->{opts}{reserved_words};
This is a hack and will eventually fail.
As per my comments above, the list of ANSI SQL reserved words (hey, which version of ANSI SQL?) is not definitive. The database itself may reserve additional words. And different versions may reserve different words. If you can find a way to do whatever it is you're doing that doesn't rely on a list of reserved words, do that.
Michael gave me this page via RT.
How about a method of SQL::Parser which returns all features of a given class (e.g. 'features($)'), analog to feature()? Would that help you? If yes, please open a feature request on CPAN against SQL::Statement.
I wouldn't break working interfaces others rely on without a good reason - missing feature is not a good reason.
If you don't want it programmatically, ignore everything I just said about SQL::Dialects and read the standard. Always check the standard as derivative works may be incomplete, incorrect or working off dialects. Even though there are updated ANSI SQL standards, most databases use some mutation of SQL-92 or elements of SQL:1999. After that they got silly.
I can't find a copy of the SQL:1999 standard, but here's a BNF which looks very thorough.
LuaSQL, which seems to be the canonical library for most SQL database systems in Lua, doesn't seem to have any facilities for quoting/escaping values in queries. I'm writing an application that uses SQLite as a backend, and I'd love to use an interface like the one specified by Python's DB-API:
c.execute('select * from stocks where symbol=?', t)
but I'd even settle for something even dumber, like:
conn:execute("select * from stocks where symbol=" + luasql.sqlite.quote(t))
Are there any other Lua libraries that support quoting for SQLite? (LuaSQLite3 doesn't seem to.) Or am I missing something about LuaSQL? I'm worried about rolling my own solution (with regexes or something) and getting it wrong. Should I just write a wrapper for sqlite3_snprintf?
I haven't looked at LuaSQL in a while but last time I checked it didn't support it. I use Lua-Sqlite3.
require("sqlite3")
db = sqlite3.open_memory()
db:exec[[ CREATE TABLE tbl( first_name TEXT, last_name TEXT ); ]]
stmt = db:prepare[[ INSERT INTO tbl(first_name, last_name) VALUES(:first_name, :last_name) ]]
stmt:bind({first_name="hawkeye", last_name="pierce"}):exec()
stmt:bind({first_name="henry", last_name="blake"}):exec()
for r in db:rows("SELECT * FROM tbl") do
print(r.first_name,r.last_name)
end
LuaSQLite3 as well an any other low level binding to SQLite offers prepared statements with variable parameters; these use methods to bind values to the statement parameters. Since SQLite does not interpret the binding values, there is simply no possibility of an SQL injection. This is by far the safest (and best performing) approach.
uroc shows an example of using the bind methods with prepared statements.
By the way in Lua SQL there is an undocumented escape function for the sqlite3 driver in conn:escape where conn is a connection variable.
For example with the code
print ("con:escape works. test'test = "..con:escape("test'test"))
the result is:
con:escape works. test'test = test''test
I actually tried that to see what it'd do. Apparently there is also such a function for their postgres driver too. I found this by looking at the tests they had.
Hope this helps.