Using Windows 7 and Creating a scheduled task based on a trigger.
The following line is resulting in "The event log query specified is invalid"
[EventData[Data[#Name='Network Client'] and (Data="C:\Program Files (x86)\AT&T Network Client\NetVC.exe")]]
I have uncovered the cause to be the ampersand in the path name "AT&T"
If I remove the ampersand then the query is understandable, but of course the path name then becomes invalid.
Is there some method where the ampersand special char can used in this situation?
Related
Expression Activity type 'VisualBasicValue`1' requires compilation in order to run. Please ensure that the workflow has been compiled.
how to solve this error
This can happen when a string with quotes is copied from a RTF formatted app, such as Microsoft Word. The " quotation character is not the code version. Try deleting the current assignment in the write cell activity and type manually so that the quotes (") are of the right type. Notice the slanted quotes vs. the straight quotes in the two examples below:
“This is a quote from an RTF app”
"This is a quote from a code editor"
I'm trying to add some constraints on database creation command in PostgreSQL.
Currently, I could do
psql -c "CREATE database \" x y\"\"z' \""
Then, I will get a database named literally " x y"z' " (without the double-quotes boundary).
It seems that pgsql supports any characters in it's database name, which is cool.
But it leads me headaches when I am doing automation stuff with bash script.
Yes, some additional work could be done to handle these cases in script. But I think these kind of names are actually meaningless (at least in my situation :), so, is there a way to add some constraints on database naming. For example, only allow [a-zA-Z0-9_.]+.
Just do not use double quotes, which you should avoid anyway if at all possible. See Documentation:
SQL identifiers and key words must begin with a letter (a-z, but also
letters with diacritical marks and non-Latin letters) or an underscore
(_). Subsequent characters in an identifier or key word can be
letters, underscores, digits (0-9), or dollar signs ($). Note that
dollar signs are not allowed in identifiers according to the letter of
the SQL standard, so their use might render applications less
portable. The SQL standard will not define a key word that contains
digits or starts or ends with an underscore, so identifiers of this
form are safe against possible conflict with future extensions of the
standard. ... There is a second kind of identifier: the delimited
identifier or quoted identifier. It is formed by enclosing an
arbitrary sequence of characters in double-quotes ("). A delimited
identifier is always an identifier, never a key word. ... Quoted
identifiers can contain any character, except the character with code
zero. (To include a double quote, write two double quotes.) This
allows constructing table or column names that would otherwise not be
possible, such as ones containing spaces or ampersands.
Not doubling quoting in you examples makes those names invalid and Postgres has no problem telling about it. So just do not use them.
Alternately you could create an event trigger. Within there you can restrict object names as needed, esp useful if you have strict naming standards. This would allow for database enforcement of those standards;
create function app_validate_table_name()
returns event_trigger
language 'plpgsql'
as $$
begin
if obj.object_identity ~! '[A-Za-z$_][[A-Za-z0-9$_]{0,62}'
then
raise exception 'App Error: Request Name (%) is invalid for <Your App Name here>',obj.object_identity;
end if
return;
end ;
$$;
create event trigger app_table_event_trigger on ddl_command_end
when tag in ('ALTER TABLE', 'CREATE TABLE')
execute procedure app_validate_table_name();
While the same can be applied to other objects it unfortunately does not seem to apply to creating a database itself.
Disclamer: The above has NOT been tested.
Was attempting to search our directory based on an attribute whose value is a DN. However, our user RDNs are of the form CN=Surname, GivenName, which requires that the comma be quoted in the full DN. But given an attribute like manager whose value is the DN of another user, I was unable to search for all users having specific manager. I tried (manager=CN=Surname\, GivenName,CN=users,DC=mydomain,DC=com), but got a syntax error "Bad search filter". I tried various options for quoting the DN, but all either gave me a syntax error or failed to match any objects. What am I doing wrong?
(Note that if I were looking for user objects directly, I could search for simply (CN=Surname, GivenName), with no quoting required, but I was searching for users having a specific manager. The comma-containing attribute value only becomes a problem when part of a Distinguished Name.)
The problem is that quoting the comma in the Common Name is not for the benefit of the filter parser, but for the benefit of the DN parser; the attribute value passed to that by the filter has to literally contain the backslash character. Unfortunately, the backslash is also (differently) special in LDAP filters, thus the syntax errors.
The solution is simple, but it isn't as obvious as doubling the backslash; backslash in LDAP filters works like % in URIs, so you have to use a literal backslash followed by the 2-digit hexadecimal code point for a backslash:
(manager=CN=Surname\5c, Givenname,OU=org,DC=mydomain,DC=com)
It turns out there's an example of this specific use case at the very bottom of https://docs.oracle.com/cd/E19424-01/820-4811/gdxpo/index.html#6ng8i269q.
I am wondering if I need to implement a solution at Datastage end and/or Oracle 11g DB end to fix the issue of existence of non-ascii characters in the descriptions. Because the databases are using different character sets, the conversion of one set to another occasionally convert a single non-ascii character into multiple characters causing a truncation error.
Sample description
": ¿What date did this happen?¿ xxxxx: ¿Wednesday, so it would have been ..... "
":had to go to the doctor yesterday.¿ xxxxxx: ¿I¿ll just get you to state your"
Ideally (for longer term) I would like to replace with the corresponding character, i.e. some extended quotes should become a regular quote.
For short term i have a sample script written which basically replaces all special characters with a space -
UPDATE rcmain.rc_description
SET desc_description = REPLACE(desc_description, CHR(191), ' ')
WHERE desc_description LIKE '%' || CHR(191) || '%'
From the above script I was to create a DataStage "ctlCleanseSourceFile" job that calls a UNIX shell script "Replace_extended_characters.sh" to strip the special characters out of the XML files.
This could be done once the XML file are merged into a single file.
Modify one of the attached sample files to create the shell script.
It should:Use the sed statement in the samples, Store a backup of the original file before the replacement. Save this to the same archive directory as the other files for the run & report on the characters replaced if possible.
Is there a better way to handle this situation and not use space to description field.
"Apologies for the long post"
Apologies, this is a quick response;
What are your NLS settings?
I had an issue like yourself reading XML and changing the source stage NLS to windows 1252 resolved the 'invalid character' issue I was having (source of the files was a windows server but Datastage was on Unix so using UTF-8)
According to the documentation for SQLDriverConnect,
Because of connection string and initialization file grammar, keywords and attribute values that contain the characters []{}(),;?*=!# not enclosed with braces should be avoided.
and
A DSN or connection string value enclosed with braces ({}) containing any of the characters []{}(),;?*=!# is passed intact to the driver.
Using the connection string DSN=%s;UID=%s;PWD={%s} works in SQLServer - infact if there are certain special characters then not enclosing the password in {} fails. However, using the same string for MS Access fails with "invalid password" and works when {} is removed. It also does not work with Oracle.
If the string enclosed in the {} is passed intact to the server, then shouldn't it work? Or am I missing something?
SQLDriverConnect's Access-specific page states that:
The PWD keyword should not include any of the special characters (see SQL_SPECIAL_CHARACTERS in SQLGetInfo Returned Values).
Calling the SQLGetInfo function while connected to Access and passing SQL_SPECIAL_CHARACTERS as the InfoType argument should return the forbidden characters #Andrew Gibson mentioned.
The "More Information" section of a knowledge base article has a list of special characters not recommended for use in an Access app.
IBM's DB2 has an identically named SQLGetInfo function with an identical parameter list and takes the same InfoType constant to return special characters, listed there as:
all characters except a...z, A...Z, 0...9, and underscore