Quantcast
Channel: SCN: Message List - SAP SQL Anywhere
Viewing all articles
Browse latest Browse all 2182

Re: SQL Anywhere and DisableBind=1, An Open Manhole Cover?

$
0
0

It's not stonewalling, or a bug, it's documented behavior that does not meet your needs.

 

 

 

The behavior of DisableBind=1 with respect to string values inserted via DataWindow is described with an example in the following excerpt from the PowerBuilder 10.2.1 Help.

 

 

 

The excerpt is discussing a different topic (how default values are handled) but it does explicitly show that the customer_ID value "A-123" is passed to SQL Anywhere as the SQL string literal 'A-123' in a SQL INSERT statement.

 

 

 

=====

 

PowerBuilder 10.2.1 Help

 

 

 

- DisableBind database parameter

 

 

 

- Setting a default column value when binding is disabled 

 

 

 

If you are not using bind variables (DisableBind set to 1) and want the

back-end DBMS to set a column to its default value when your application

user does not explicitly enter a value in a new row, you do not need to

set an initial value for the DataWindow column.

 

 

 

This is because with bind variables disabled, the DataWindow painter

generates a SQL INSERT statement for each row added to the DataWindow

object. If a column does not contain an explicit value, it is not

included in the SQL INSERT statement.

 

 

 

Using the Order_T table example, if your application user enters 123

as the value for the Order_ID column and A-123 as the value for the

Customer_ID column, the DataWindow painter generates the following

SQL INSERT statement when DisableBind is set to 1 (binding disabled):

 

 

 

INSERT INTO Order_T(Order_ID, Customer_ID)

 

 

 

        VALUES(123, 'A-123')

 

 

 

Your back-end DBMS would then set the Order_Date column to its default

value as expected, since a value for Order_Date is not explicitly set

in the SQL INSERT statement generated by the DataWindow painter.

 

=====

 

 

 

On the SQL Anywhere side of things, the handling of \n inside 'quoted string literals' has been documented in the same location of the Help ever since (at least) Watccom 5.5:

 

 

 

====

 

SQL Anywhere User's Guide

 

 

 

- PART 6. SQL Anywhere Reference

 

 

 

- CHAPTER 40. Watcom-SQL Language Reference

 

 

 

- Watcom-SQL language elements

 

 

 

string - Any sequence of characters enclosed in apostrophes ('single quotes').

 

An apostrophe is represented inside the string by two apostrophes in a row.

 

A new line character is represented by a backslash followed by an n (\n).

 

Hexadecimal escape sequences can be used for any character, printable or not.

 

A hexadecimal escape sequence is a backslash followed by an x followed by two

hexadecimal digits (for example, \x6d represents the letter m).

 

A backslash character is represented by two backslashes in a row (\\).

 

 

 

The following are valid strings:

 

 

 

'This is a string.'

 

 

 

'John''s database'

 

 

 

'\x00\x01\x02\x03'

 

=====

 

 

 

Sooo... the rule is, and has always been, this: If you don't want \n to be treated as a new line character then don't embed it inside a 'quoted string literal' in Watcom SQL.

 

 

 

Although there are a handful of exceptions, they don't apply to INSERT statements generated by PowerBuilder.


Viewing all articles
Browse latest Browse all 2182

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>