Where are the values in SQL Preview?

SQL Anywhere Survival Guide
This problem is quite common with SQL Anywhere newbies and can be a source of a lot of frustration. When one examines the value of the 'sqlsyntax' argument in the 'sqlpreview' event of a datawindow, one finds question marks instead of the actual value being submitted to the database. Example- This behavior is due to a feature provided by PowerBuilder known a 'Binding' which can result in improved performance. In short, if binding is on PowerBuilder does not compile a SQL statement every time it has to be executed. Instead it is just compiles it once with 'Bind variables' used as place holders for actual values. After that the compiled statement can be executed many times with the actual values substituted. The question marks seen in SQL Preview are the place holders, and in order to see the actual data, the binding must be turned off. This can be done by specifying 'DisbleBind=1' in the transaction object's DBPARM. Example- For more information on DisableBind see 'DisableBind DBParm parameter' in the online help.
 
 
 Hiding the SQL Anywhere DB Engine Window

SQL Anywhere Survival Guide
Did you ever wish that the SQL Anywhere DB Engine window(the one that is opened when you start a database) would be invisible and run like a service on Windows NT or at least run as an icon in the system tray. I always worry that my users will shut the engine off by mistake. Well, it is quite simple to do this by specifying a parameter to the DB Engine executable - This should be specified as the Start Command in the datasource's ODBC settings under Database Startup Options.
 

 Problems with Identity/Autoincrement Columns


SQL Anywhere Survival Guide
I faced a few problems with PB5.0.1 and SQL Anywhere's Identity or Default AUTOINCREMENT columns. So I posted this problem on the SQL Anywhere forum and the PB-L List.
 
Hi,
        Is anybody aware of PB's(5.0.1) problems with handling Identity/Default Autoincrement columns in SQL Anywhere 5.0.1? PB hadles things just fine if the datatype is 'Integer'. The problem is when you define the datatype of the column to be Numeric(X,Y). In this case, on inserting a new row into
the table, PB fails to retrieve the correct value generated into the datawindow column.

Example, if  we define a table as -

CREATE TABLE "dba"."myemp"
        ("id" numeric(9,0) NOT NULL DEFAULT autoincrement,
        "name" char(25) NOT NULL
        , PRIMARY KEY ("id"));

Now, when I insert rows into this table, the values generated for the "id" column will be 1,2,3,.... and these should be automatically retrieved by PB. But PB retrieves some junk value instead. It's not that SQLA generates incorrect values, it just that PB seems to retrieve junk values instead of
the generated ones.

This feature works fine if I define the datatype of the column to be Integer. This behaviour can be verified even in the Database painter. Is this some PB bug? Has it been fixed in subsequent patches or PB6.0?

Jiggy

Here are some of the responses to this post:
 
I had the same problem. I went to PB 5.0.3 and it was solved.  
   
Hope this helps...  
Amy Thompson  
dtainc@mindspring.com
I tested under PB 5.0.03/SQLA 5.5.03. It returned the huge junk value.  
Then, I tested under PB 6 Beta Build 247 (the last public beta)/SQLA 5.5.03 and it returned a nice reasonable number.  
If they didn't change the code in the GA, I would dare to say that it has been fixed in PB 6 :). Don't know about 5.0.04.  

Hope this helps,  

Juan Bautista Nunez R.  
Softronix, Inc. (Panama City, Panama)  
jbnunez@usa.net 
Jiggy,  

    There is also a 'bug' in pb 5.0.03 regarding Autoincrement fields:  
When you deploy, make sure that your PB dlls are in the same directory as your application, otherwise autoincrement columns may not be incremented properly. (Issue # 480781)  

Have fun,  
Bernard Mikowski  
bmikowski@mesgroup.com 
 

Executable does not connect to the Database


SQL Anywhere Survival Guide
This one has got to be the most often posted problem on any PB forum. The typical sob story goes as follows: More often than not, the only cause is that the SQL Anywhere directory, usually X:\SQLAny50\Win or X:\SQLAny50\Win32,  is not in the Application or the System Path.

In case of Win 3.x, the SQL Anywhere directory, should be included in the system path by changing the AUTOEXEC.BAT file.

Win95 and WinNT provide an alternative in the form of the Application path. Each executable can have it's own search path. This can be done by editing the entries in the following section of the Registry -
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths.

The reason that the application manages to connect when running in the development environment is that the PowerBuilder executable PB050.EXE has the SQL Anywhere directory in it's search path.

Hiding the ODBC logon window


SQL Anywhere Survival Guide
Sometimes(it doesn't happen with me consistently) when a user's login attempt fails the ODBC logon window automatically pops up. To prevent this put the following in your DBParm before connecting- Example-

Back to my HomePage
  1