As a part of DB migration, we are moving to PostgreSQL and we observed that extra "" is inserting in bytea column of Quartz table. If we set the parameter "Standard_Conforming_strings" to off, we are able to save the data in proper format. As a part of our scenario, our record uses xml file as a input parameter and we are suspecting that by setting that parameter this setting may omit "" characters which are in xml file.
Can anyone suggest by setting this parameter to "off" is there any impact?
WPF application
PostgreSQL v11
Quartz 1.0.3.3
nHibernate 3.0.4000
dotconnectforPostgreSQL
We tried setting the "Standard_Conforming_strings" to off and its working . But we want to know the impact of this parameter change.
The impact is that sequences such as \n or \t (there are more) start having a special, non standard conforming, meaning in string literals: they are interpreted as special characters (in this case, newline and tabulator).
This is a leftover from the old days, when that was the normal behavior of PostgreSQL. If your client software needs that setting to work properly, that may be because you are using very old drivers to access the database (or the application itself is very old). Upgrading the client libraries and drivers may help.
Related
While, in SQL, you can use double quotes to write identifiers in any case, DBMSes also have a "default" case that is used if the identifier isn't quoted. For example, PostgreSQL converts unquoted identifiers to lower case, while Snowflake converts them to upper case.
Does JDBC define a standard way of telling which it is for a particular DBMS?
In theory the following methods from DatabaseMetaData should give you that information:
storesUpperCaseIdentifiers()
storesUpperCaseQuotedIdentifiers()
storesLowerCaseIdentifiers()
storesLowerCaseQuotedIdentifiers()
storesMixedCaseIdentifiers()
storesMixedCaseQuotedIdentifiers()
But in my experience the information returned by the various drivers isn't 100% reliable.
The Postgres driver correctly reports storesLowerCaseIdentifiers = true.
The MySQL driver does not check the server's configuration e.g. the various combinations of the file system's behaviour, lower_case_table_names and innodb_file_per_table.
I have a case where addresses and country names have special characters. For eg:
People's Republic of Korea
De'Paul & Choice Street
etc..
This data get send as JSON payload to backend to be inserted in a JSONB column in postgres.
The insert statement gets messed up because of the "single quote" and ends up erroring out.
The front-end developers are saying that they are using popular libraries to get country names etc and don't want to touch the data. They just want to pass as is.
Any tips on how to process such data with special characters especially something that contradicts with JSON formatted data and safely insert into postgres?
Your developers are using the popular libraries, whatever they may be, in the wrong fashion. The application is obviously vulnerable to SQL injection, the most popular way to attack a database application.
Use prepared statements, then the problem will go away. If you cannot do that, use the popular library's functions to escape the input string for use as an SQL string literal.
Some people in my company have gone to great lengths to remove & characters from data and measure names in our Tabular models. I wasn't around when they made this decision, but it destroys readability in our financial reporting. Instead of R&D and SG&A in our statements, we have RD and SGA.
The offenders are no longer around to answer for their crimes. I am trying to convince my co-workers to re-add the &, but they won't budge without some idea why this was done in the first place. My best guess is that a consultant told them not to use & in models. I think they meant in object names only, but our team got carried away. I've been able to find this page that says & was a reserved character in Compatibility Level 1100, but that goes back to SQL Server 2012! I think our lowest environment is SSAS 2017.
Am I missing anything or can we re-add & to our data and measure names? Is there any reason you would avoid the use of & anywhere in an SSAS tabular model? Links to documentation appreciated!
https://learn.microsoft.com/en-us/analysis-services/multidimensional-models/olap-physical/object-naming-rules-analysis-services?view=asallproducts-allversions
Exceptions: When Reserved Characters are Allowed
As noted, databases of a specific modality and compatibility level can have object names that include reserved characters. Dimension attribute, hierarchy, level, measure and KPI object names can include reserved characters, for tabular databases (1103 or higher) that allow the use of extended characters:
Server mode and database compatibility level Reserved characters allowed?
Databases can have a ModelType of default. Default is equivalent to multidimensional, and thus does not support the use of reserved characters in column names.
I have ormlite integrated into an application I'm working on. Right now I'm trying to build in functionality to easily switch from automatically inserting data to the database to outputting the equivalent collection of insert statements to a file for later use. The data isn't user input but still requires proper escaping to handle basic gotchas like apostrophes.
Ideas I've burned through:
Dao.create() writes to the database directly, so that's a no-go.
QueryBuilder can't handle inserts.
JdbcDatabaseConnection.compileStatement() might work but the amount of setup required is inappropriate.
Using a java.sql.PreparedStatement has a reasonable enough interface (if toString() returns the SQL like I would hope) but it's not compatible with ormlite's connection types.
This should be very easy and if it is, I can't find the right combination of method calls to make it happen.
Right now I'm trying to build in functionality to easily switch from automatically inserting data to the database to outputting the equivalent collection of insert statements to a file for later use.
Interesting. So one hack would be to use the MappedCreate class. The MappedCreate.build(...) method takes a DatabaseType and a TableInfo which is available from the dao.getTableInfo().
The mappedCreate.toString() exposed the generated INSERT statement (with a prefix) which might help but you would still need to convert the ? arguments to be the actual values with escaped quotes. That you would have to do in your own code.
Hope this helps somewhat.
How can I disable string escape in $db->insert, I need to insert html in my database, so I don't want any string escape.Any solutions?
You don't want to disable that escaping.
Escaping data doesn't prevent you from inserting anything. In fact, quite the opposite: escaping data enables you to properly insert characters like quote marks that could otherwise confuse the database. More importantly, passing unescaped data directly to a database exposes an enormous security hole, making it trivial for a "hacker" (if we use the term liberally) to gain unrestricted access to your site and to your database.
You're probably confusing SQL escaping (which escapes data for use in SQL queries) with htmlspecialchars(), which escapes data for use on webpages. The two are unrelated.