Long Varchar (binary) data handling in Team Developer 5.1

Discussions specific to Team Developer 5.1.

Long Varchar (binary) data handling in Team Developer 5.1

Postby jmgemperle » Fri Feb 29, 2008 8:13 am

A change in behavior was introduced in Team Developer 5.1 in regards to long varchar (binary) data handling.

A documentation bug was logged to address the new behavior:
TD-4380: Improve online help to detail the change in behavior of SqlSetLongBindDatatype() when fetching Long Varchar (binary)

Please read below before migrating applications to TD5.1 which use BLOB data or when creating new applications in that version.

Change in behavior
- SqlSetLongBindDatatype() function must be called during fetch operations
- SqlSetLongBindDatatype() must be called just after SqlFetchNext(), not before SqlPrepareAndExecute() as usual in previous TD versions. Calling it before SqlPrepareAndExecute() only works if no bind variable is used in the Where clause.

Sample code

Code: Select all
Call SalListQueryText( lb1, SalListQuerySelection( lb1 ), sSearch )
Call SalMessageBox("Just a TEST using litteral FKB in the where clause... it is OK","info",0)
Set sSelect = "SELECT employee_id, first_name, last_name, photo
                     FROM employee
                     INTO :dfsEMPLOYEE_ID, :dfsFIRST_NAME, :dfsLAST_NAME, :lPhoto
                     WHERE employee_id = 'FKB' "
!!Bind position okay for this fetch. Here it works before the SqlPrepareAndExecute call. Not calling
!!at all SqlSetLongBindDatatype() will fail in TD 5.1, not in previous TD versions
Call SqlSetLongBindDatatype( 4,23 )
Call SqlPrepareAndExecute( hSql, sSelect )
If SqlFetchNext( hSql, nFetch )
Call SalPicSetString( pic1, PIC_FormatObject, lPhoto )

Call SalMessageBox("Now problem searching with BIND variable, you selected to search photo of :" || sSearch,"info",0)
Set sSelect = 'SELECT employee_id, first_name, last_name, photo
                    FROM employee
                    INTO :dfsEMPLOYEE_ID, :dfsFIRST_NAME, :dfsLAST_NAME, :lPhoto
                    WHERE employee_id = :sSearch '
!!You must call SqlSetLongBindDatatype for the fetch operation and this needs to be done just before SqlFetchNext
!!In previous versions this was necessary for the select only
!!Calling SqlSetLongBindDatatype here, before the SqlPrepareAndExecute() will not work
! Call SqlSetLongBindDatatype(4,23 )
Call SqlPrepareAndExecute( hSql, sSelect )
! Here it does. This is now as-designed
Call SqlSetLongBindDatatype(4,23 )
If SqlFetchNext( hSql, nFetch )
Call SalPicSetString( pic1, PIC_FormatObject, lPhoto )
Last edited by apaula on Fri Aug 08, 2008 11:17 am, edited 1 time in total.
User avatar
jmgemperle
 
Posts: 886
Joined: Thu Feb 15, 2007 1:57 am
Location: Leiden The Netherlands

Re: Long Varchar (binary) data handling in Team Developer 5.1

Postby vg » Thu Aug 14, 2008 5:27 am

This is a very good step in the right direction. If you read even the online documentation it ends on MS Sql Server 7.

Can you also tell using which database connectivity : routers (which), OleDB, database datatypes and TD datatypes does it apply to.
I think now we can have more than one LOB column per table. Do we make many calls to SqlSetLongBindDatatype ?

And since we have to do it between Execute and Fetch what happens when you Execute another SQl. Do these flags get cleared?
If they do - why do we have to reset types back at all?
If they do not - why between Execute and Fetch is the only place?
vg
 
Posts: 17
Joined: Thu Oct 11, 2007 5:27 am


Return to Team Developer 5.1

Who is online

Users browsing this forum: No registered users and 2 guests