Home > Archive > SQL Anywhere Mobile > April 2005 > Issues with Long Varchar DataType









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Issues with Long Varchar DataType
Kevin Dunn

2005-04-20, 11:24 am

We are using ASA 9.01.1841 and there seems to be a problem when a remote user inserts a value into a LONG VARCHAR data type.

THe column has a value in the remote database but when it comes up to the consolidated, it is treated as a NULL. In the following piece of the log file the long varchar field states [60 characters], the column is called purpose_of_vist in the Select statement. Why is this happening? It seems to be this one remote database. Other databases are replicating fine.

E. 04/20 10:51:49. <2.2> [arobbins]: Error: [-10002] ODBC: [Sybase][ODBC Driver][Adaptive Server Anywhere]Integrity constraint violation: Column 'purpose_of_visit' in table 'ist_general' cannot be NULL (ODBC State = 23000, Native error code = -195)
I. 04/20 10:51:49. <2.1> [lnobbs]: Translated SQL:
savepoint it120
E. 04/20 10:51:49. <2.2> [arobbins]: Error: Unable to insert into table 'ist_general' using upload_cursor
I. 04/20 10:51:49. <2.2> [arobbins]: Error Context:
I. 04/20 10:51:49. <2.2> [arobbins]: User Name: arobbins
I. 04/20 10:51:49. <2.2> [arobbins]: Modified User Name: arobbins
I. 04/20 10:51:49. <2.2> [arobbins]: Transaction: upload
I. 04/20 10:51:49. <2.2> [arobbins]: Table Name: ist_general
I. 04/20 10:51:49. <2.2> [arobbins]: Insert Row:
I. 04/20 10:51:49. <2.2> [arobbins]: 3846010460928200101
I. 04/20 10:51:49. <2.2> [arobbins]: 3845911053088700101
I. 04/20 10:51:49. <2.2> [arobbins]: 2005-04-18 00:00:00.000000
I. 04/20 10:51:49. <2.2> [arobbins]: 2005-04-24 00:00:00.000000
I. 04/20 10:51:49. <2.2> [arobbins]: C00107460 AR517
I. 04/20 10:51:49. <2.2> [arobbins]: 38455833480020006801
6
I. 04/20 10:51:49. <2.2> [arobbins]: 3845911254157800101
I. 04/20 10:51:49. <2.2> [arobbins]: NULL
I. 04/20 10:51:49. <2.2> [arobbins]: [60 Characters]
I. 04/20 10:51:49. <2.2> [arobbins]: 1
I. 04/20 10:51:49. <2.2> [arobbins]: NULL
I. 04/20 10:51:49. <2.2> [arobbins]: NULL
I. 04/20 10:51:49. <2.2> [arobbins]: 27
I. 04/20 10:51:49. <2.2> [arobbins]: 2005-04-20 10:55:53.362000
I. 04/20 10:51:49. <2.2> [arobbins]: 38455834280010006561
2
I. 04/20 10:51:49. <2.2> [arobbins]: 2005-04-20 10:46:09.272000
I. 04/20 10:51:49. <2.2> [arobbins]: A
I. 04/20 10:51:49. <2.2> [arobbins]: 900101
I. 04/20 10:51:49. <2.2> [arobbins]: 900101
I. 04/20 10:51:49. <2.2> [arobbins]: 38455834280010006561
2
I. 04/20 10:51:49. <2.2> [arobbins]: 2005-04-20 10:46:09.272000
I. 04/20 10:51:49. <2.2> [arobbins]: 12
I. 04/20 10:51:49. <2.2> [arobbins]: Script Version: ORAPist20
I. 04/20 10:51:49. <2.2> [arobbins]: Script: SELECT ist_general_id, entity_id, begin_date, end_date, work_order_num, report_author_id, primary_site_contact
, secondary_site_conta
ct, purpose_of_visit,
report_type_id, report_locked, report_completed, data_source, mod_datetime, mod_user, loaded_date, status, site_id, source_site_id, add_user, add_datetime, contract_holder_id
FROM ist_general
WHERE ist_general_id = ?

--
Kevin Dunn
Email: kevin.dunn@spsinc.com
Home Email: kdunn2@carolina.rr.com
H: 704-263-2450
W: 704-544-5501 ext 295
Greg Fenton

2005-04-20, 8:24 pm

Kevin Dunn wrote:
> We are using ASA 9.01.1841 and there seems to be a problem when a remote
> user inserts a value into a LONG VARCHAR data type.
>


Try running the ML server with "-v+" and dbmlsync with the extended
option SendColumnNames set to ON. Then, in the ML log at the beginning
of the synchronization session, the remote's schema for that table will
be displayed. Compare the *order* of the columns in the log with the
order of the columns in your synch script. If in your script you have
reversed a couple of columns, it is possible that the NULL is being
inserted into the wrong column.

greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
Kevin Dunn

2005-04-20, 8:24 pm

The columns are correct. In the error output that was written to the
dbmlsrv log shows the fields in the correct order, the only thing I see is
that for the long varchar value it just states:
I. 04/20 10:51:49. <2.2> [arobbins]: Insert Row:
I. 04/20 10:51:49. <2.2> [arobbins]: 3846010460928200101
I. 04/20 10:51:49. <2.2> [arobbins]: 3845911053088700101
I. 04/20 10:51:49. <2.2> [arobbins]: 2005-04-18 00:00:00.000000
I. 04/20 10:51:49. <2.2> [arobbins]: 2005-04-24 00:00:00.000000
I. 04/20 10:51:49. <2.2> [arobbins]: C00107460 AR517
I. 04/20 10:51:49. <2.2> [arobbins]: 38455833480020006801
6
I. 04/20 10:51:49. <2.2> [arobbins]: 3845911254157800101
I. 04/20 10:51:49. <2.2> [arobbins]: NULL
I. 04/20 10:51:49. <2.2> [arobbins]: [60
----------This should be text, this is a long varchar datatype.

--
Kevin Dunn
Email: kevin.dunn@spsinc.com
Home Email: kdunn2@carolina.rr.com
H: 704-263-2450
W: 704-544-5501 ext 295
"Greg Fenton" <greg. fenton_NOSPAM_@ianyw
here.com> wrote in message
news:4266ed9c$1@foru
ms-2-dub...
> Kevin Dunn wrote:
>
> Try running the ML server with "-v+" and dbmlsync with the extended
> option SendColumnNames set to ON. Then, in the ML log at the beginning
> of the synchronization session, the remote's schema for that table will
> be displayed. Compare the *order* of the columns in the log with the
> order of the columns in your synch script. If in your script you have
> reversed a couple of columns, it is possible that the NULL is being
> inserted into the wrong column.
>
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/



Greg Fenton

2005-04-21, 3:24 am

Kevin Dunn wrote:
> The columns are correct.


Just to be sure...are you sure? The order of the columns is
*completely* dependent on the order that the *remote* sends up (thus the
reason I suggest the SendColumnNames approach).

> I. 04/20 10:51:49. <2.2> [arobbins]: [60
> ----------This should be text, this is a long varchar datatype.


Hmmm...not sure about how we display LONG VARCHAR. ML only displays the
size of a field for LONG BINARY, so its possible it does the same for
LONG VARCHAR (thus avoiding having to truncate the string).

greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/
Sponsored Links





Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive | Programming forum archive

Copyright 2008 droptable.com