sqlchar to sqllvarchar
Hi Gurus,=0D=0A=0D=0AWe have some data to be retrieved using System Descrip= tor Area=2E=0D=0A=0D=0A"SELECT claimrefno || '\\\\t' || claimvendorname||'\\\\t' = || b3acctsecurno || '\\\\t' || b3transno || '\\\\t' || description ||'\\\\t'|| round= (claimamount,2) || '\\\\t' || statemodeldesc || '\\\\t' from %s"=0D=0A=0D=0AThe s= elected data type is SQLCHAR when we are using ESQL Version 2=2E90=2EUC4R1= =2E=2E=0D=0AHowever after we upgrade to ESQL Version 3=2E5UC3, the data typ= e changed to SQLLVARCHAR?=0D=0A=0D=0AAnybody has idea why it changed?=0D=0A= =0D=0AThanks,=0D=0ADenny=0D=0A*******************************************= =0D=0A=0D=0AThe information contained in this e-mail message may =0D=0Acont= ain privileged and confidential information=2E =0D=0AIf you are not the int= ended recipient, you are =0D=0Ahereby notified that any review, disseminati= on, =0D=0Adistribution or duplication of this communication =0D=0Ais strict= ly prohibited=2E If you have received this =0D=0Amessage in error, please n= otify the sender by return =0D=0Ae-mail, delete this message and destroy an= y copies=2E =0D=0AInternet e- mail is not guaranteed to be secure or =0D=0A= error-free=2E Messages could be intercepted, corrupted, =0D=0Alost, arrive = late or contain viruses=2E =0D=0AThe sender will not be liable for =0D=0Ath= ese risks=2E =0D=0A=0D=0A******************************************* =0D=0A= Ce message =E9lectronique pourrait contenir des informations=0Aprivil=E9gi= =E9es et confidentielles=2E Si vous n'en =EAtes pas le=0Ar=E9cipiendaire pr= =E9vu, nous vous signalons qu'il est strictement=0Ainterdit d'examiner, de = diffuser, de distribuer et de reproduire le=0Apr=E9sent message=2E Si vous = l'avez re=E7u par erreur, veuillez pr=E9venir=0Al'exp=E9diteur par courriel= , puis effacer ce message et en d=E9truire=0Atoute copie=2E Le courrier =E9= lectronique n'est pas garanti s=E9curitaire=0Ani exempt d'erreurs=2E Les me= ssages pourraient =EAtre intercept=E9s,=0Acorrompus, =E9gar=E9s, retard=E9s= ou contamin=E9s par des virus=2E=0AL'exp=E9diteur n'est pas responsable de= ces risques=2E
Translation: We have some data to be retrieved using System Descriptor Area: "SELECT claimrefno || '\\\\t' || claimvendorname||'\\\\t' || b3acctsecurno || '\\\\t' || b3transno || '\\\\t' || description ||'\\\\t' || round(claimamount,2) || '\\\\t' || statemodeldesc || '\\\\t' from %s" The selected data type is SQLCHAR when we are using ESQL Version 2.90.UC4R1 However after we upgrade to ESQL Version 3=2E5UC3, the data type changed to SQLLVARCHAR? Anybody has idea why it changed? Thanks, Denny Because you are concatenating data into a string and apparently IBM has changed the datatype of concatenated data internal to the engine from fixed CHAR to variable length LVARCHAR. SDK v2.90 dates back to IDS 9.30 days before there was an LVARCHAR data type. That's the most likely reason you are first seeing this change now. This should not affect the application. LVARCHAR maps well into 'C' char type host variables (just be careful if you are using a char pointer that the allocated memory is large enough to hold any value being returned as the library will not be able to truncate the data since it won't know the actual length of the host variable memory at compile time). Note that you can just use the SET DESCRIPTOR statement to modify the data type of the returning data back to fixed character (CHAR, FIXCHAR, or STRING) and the engine will make any required conversion. Art 2009/2/12 Guo, Denny <DGuo@livingstonintl.com> > Hi Gurus,=0D=0A=0D=0AWe have some data to be retrieved using System > Descrip= > tor Area=2E=0D=0A=0D=0A"SELECT claimrefno || '\\\\t' || claimvendorname||'\\\\t' > = > || b3acctsecurno || '\\\\t' || b3transno || '\\\\t' || description ||'\\\\t'|| > round= > (claimamount,2) || '\\\\t' || statemodeldesc || '\\\\t' from %s"=0D=0A=0D=0AThe > s= > elected data type is SQLCHAR when we are using ESQL Version 2=2E90=2EUC4R1= > =2E=2E=0D=0AHowever after we upgrade to ESQL Version 3=2E5UC3, the data > typ= > e changed to SQLLVARCHAR?=0D=0A=0D=0AAnybody has idea why it > changed?=0D=0A= > =0D=0AThanks,=0D=0ADenny=0D=0A*******************************************= > =0D=0A=0D=0AThe information contained in this e-mail message may > =0D=0Acont= > ain privileged and confidential information=2E =0D=0AIf you are not the > int= > ended recipient, you are =0D=0Ahereby notified that any review, > disseminati= > on, =0D=0Adistribution or duplication of this communication =0D=0Ais > strict= > ly prohibited=2E If you have received this =0D=0Amessage in error, please > n= > otify the sender by return =0D=0Ae-mail, delete this message and destroy > an= > y copies=2E =0D=0AInternet e- mail is not guaranteed to be secure or > =0D=0A= > error-free=2E Messages could be intercepted, corrupted, =0D=0Alost, arrive > = > late or contain viruses=2E =0D=0AThe sender will not be liable for > =0D=0Ath= > ese risks=2E =0D=0A=0D=0A******************************************* > =0D=0A= > Ce message =E9lectronique pourrait contenir des informations=0Aprivil=E9gi= > =E9es et confidentielles=2E Si vous n'en =EAtes pas le=0Ar=E9cipiendaire > pr= > =E9vu, nous vous signalons qu'il est strictement=0Ainterdit d'examiner, de > = > diffuser, de distribuer et de reproduire le=0Apr=E9sent message=2E Si vous > = > l'avez re=E7u par erreur, veuillez pr=E9venir=0Al'exp=E9diteur par > courriel= > , puis effacer ce message et en d=E9truire=0Atoute copie=2E Le courrier > =E9= > lectronique n'est pas garanti s=E9curitaire=0Ani exempt d'erreurs=2E Les > me= > ssages pourraient =EAtre intercept=E9s,=0Acorrompus, =E9gar=E9s, > retard=E9s= > ou contamin=E9s par des virus=2E=0AL'exp=E9diteur n'est pas responsable de= > ces risques=2E > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. --0016e644d6cad92b090462bcf740
Thanks Art, That is what I just found out. I try to change the select statement and the data type changed from lvarchar -> varchar -> char. Good to know. Thanks again. Denny -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel Sent: Thursday, February 12, 2009 1:34 PM To: ids@iiug.org Subject: Re: sqlchar to sqllvarchar [14873] Translation: We have some data to be retrieved using System Descriptor Area: "SELECT claimrefno || '\\t' || claimvendorname||'\\t' || b3acctsecurno || '\\t' || b3transno || '\\t' || description ||'\\t' || round(claimamount,2) || '\\t' || statemodeldesc || '\\t' from %s" The selected data type is SQLCHAR when we are using ESQL Version 2.90.UC4R1 However after we upgrade to ESQL Version 3=2E5UC3, the data type changed to SQLLVARCHAR? Anybody has idea why it changed? Thanks, Denny Because you are concatenating data into a string and apparently IBM has changed the datatype of concatenated data internal to the engine from fixed CHAR to variable length LVARCHAR. SDK v2.90 dates back to IDS 9.30 days before there was an LVARCHAR data type. That's the most likely reason you are first seeing this change now. This should not affect the application. LVARCHAR maps well into 'C' char type host variables (just be careful if you are using a char pointer that the allocated memory is large enough to hold any value being returned as the library will not be able to truncate the data since it won't know the actual length of the host variable memory at compile time). Note that you can just use the SET DESCRIPTOR statement to modify the data type of the returning data back to fixed character (CHAR, FIXCHAR, or STRING) and the engine will make any required conversion. Art 2009/2/12 Guo, Denny <DGuo@livingstonintl.com> > Hi Gurus,=0D=0A=0D=0AWe have some data to be retrieved using System > Descrip= > tor Area=2E=0D=0A=0D=0A"SELECT claimrefno || '\\t' || claimvendorname||'\\t' > = > || b3acctsecurno || '\\t' || b3transno || '\\t' || description ||'\\t'|| > round= > (claimamount,2) || '\\t' || statemodeldesc || '\\t' from %s"=0D=0A=0D=0AThe > s= > elected data type is SQLCHAR when we are using ESQL Version 2=2E90=2EUC4R1= > =2E=2E=0D=0AHowever after we upgrade to ESQL Version 3=2E5UC3, the data > typ= > e changed to SQLLVARCHAR?=0D=0A=0D=0AAnybody has idea why it > changed?=0D=0A= > =0D=0AThanks,=0D=0ADenny=0D=0A*******************************************= > =0D=0A=0D=0AThe information contained in this e-mail message may > =0D=0Acont= > ain privileged and confidential information=2E =0D=0AIf you are not the > int= > ended recipient, you are =0D=0Ahereby notified that any review, > disseminati= > on, =0D=0Adistribution or duplication of this communication =0D=0Ais > strict= > ly prohibited=2E If you have received this =0D=0Amessage in error, please > n= > otify the sender by return =0D=0Ae-mail, delete this message and destroy > an= > y copies=2E =0D=0AInternet e- mail is not guaranteed to be secure or > =0D=0A= > error-free=2E Messages could be intercepted, corrupted, =0D=0Alost, arrive > = > late or contain viruses=2E =0D=0AThe sender will not be liable for > =0D=0Ath= > ese risks=2E =0D=0A=0D=0A******************************************* > =0D=0A= > Ce message =E9lectronique pourrait contenir des informations=0Aprivil=E9gi= > =E9es et confidentielles=2E Si vous n'en =EAtes pas le=0Ar=E9cipiendaire > pr= > =E9vu, nous vous signalons qu'il est strictement=0Ainterdit d'examiner, de > = > diffuser, de distribuer et de reproduire le=0Apr=E9sent message=2E Si vous > = > l'avez re=E7u par erreur, veuillez pr=E9venir=0Al'exp=E9diteur par > courriel= > , puis effacer ce message et en d=E9truire=0Atoute copie=2E Le courrier > =E9= > lectronique n'est pas garanti s=E9curitaire=0Ani exempt d'erreurs=2E Les > me= > ssages pourraient =EAtre intercept=E9s,=0Acorrompus, =E9gar=E9s, > retard=E9s= > ou contamin=E9s par des virus=2E=0AL'exp=E9diteur n'est pas responsable de= > ces risques=2E > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. --0016e644d6cad92b090462bcf740 ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. ******************************************* The information contained in this e-mail message may contain privileged and confidential information. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you have received this message in error, please notify the sender by return e-mail, delete this message and destroy any copi
Update statistics? No RAID5? Art On Thu, Feb 12, 2009 at 1:43 PM, Guo, Denny <DGuo@livingstonintl.com> wrote: > > Thanks Art, > > That is what I just found out. > I try to change the select statement and the data type changed from lvarchar -> varchar -> char. > Good to know. > > Thanks again. > Denny > > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel > Sent: Thursday, February 12, 2009 1:34 PM > To: ids@iiug.org > Subject: Re: sqlchar to sqllvarchar [14873] > > > Translation: > > We have some data to be retrieved using System Descriptor Area: > > "SELECT claimrefno || '\\t' || claimvendorname||'\\t' > > || b3acctsecurno || '\\t' || b3transno || '\\t' || description > ||'\\t' > > || round(claimamount,2) || '\\t' || statemodeldesc || '\\t' > from %s" > > The selected data type is SQLCHAR when we are using ESQL Version 2.90.UC4R1 > However after we upgrade to ESQL Version 3=2E5UC3, the data type changed to > SQLLVARCHAR? > > Anybody has idea why it changed? > > Thanks, > Denny > > Because you are concatenating data into a string and apparently IBM has > changed the datatype of concatenated data internal to the engine from fixed > CHAR to variable length LVARCHAR. SDK v2.90 dates back to IDS 9.30 days > before there was an LVARCHAR data type. That's the most likely reason you > are first seeing this change now. This should not affect the application. > LVARCHAR maps well into 'C' char type host variables (just be careful if you > are using a char pointer that the allocated memory is large enough to hold > any value being returned as the library will not be able to truncate the > data since it won't know the actual length of the host variable memory at > compile time). > > Note that you can just use the SET DESCRIPTOR statement to modify the data > type of the returning data back to fixed character (CHAR, FIXCHAR, or > STRING) and the engine will make any required conversion. > > Art > > 2009/2/12 Guo, Denny <DGuo@livingstonintl.com> > > > Hi Gurus,=0D=0A=0D=0AWe have some data to be retrieved using System > > Descrip= > > tor Area=2E=0D=0A=0D=0A"SELECT claimrefno || '\\t' || claimvendorname||'\\t' > > = > > || b3acctsecurno || '\\t' || b3transno || '\\t' || description ||'\\t'|| > > round= > > (claimamount,2) || '\\t' || statemodeldesc || '\\t' from %s"=0D=0A=0D=0AThe > > s= > > elected data type is SQLCHAR when we are using ESQL Version 2=2E90=2EUC4R1= > > =2E=2E=0D=0AHowever after we upgrade to ESQL Version 3=2E5UC3, the data > > typ= > > e changed to SQLLVARCHAR?=0D=0A=0D=0AAnybody has idea why it > > changed?=0D=0A= > > =0D=0AThanks,=0D=0ADenny=0D=0A*******************************************= > > =0D=0A=0D=0AThe information contained in this e-mail message may > > =0D=0Acont= > > ain privileged and confidential information=2E =0D=0AIf you are not the > > int= > > ended recipient, you are =0D=0Ahereby notified that any review, > > disseminati= > > on, =0D=0Adistribution or duplication of this communication =0D=0Ais > > strict= > > ly prohibited=2E If you have received this =0D=0Amessage in error, please > > n= > > otify the sender by return =0D=0Ae-mail, delete this message and destroy > > an= > > y copies=2E =0D=0AInternet e- mail is not guaranteed to be secure or > > =0D=0A= > > error-free=2E Messages could be intercepted, corrupted, =0D=0Alost, arrive > > = > > late or contain viruses=2E =0D=0AThe sender will not be liable for > > =0D=0Ath= > > ese risks=2E =0D=0A=0D=0A******************************************* > > =0D=0A= > > Ce message =E9lectronique pourrait contenir des informations=0Aprivil=E9gi= > > =E9es et confidentielles=2E Si vous n'en =EAtes pas le=0Ar=E9cipiendaire > > pr= > > =E9vu, nous vous signalons qu'il est strictement=0Ainterdit d'examiner, de > > = > > diffuser, de distribuer et de reproduire le=0Apr=E9sent message=2E Si vous > > = > > l'avez re=E7u par erreur, veuillez pr=E9venir=0Al'exp=E9diteur par > > courriel= > > , puis effacer ce message et en d=E9truire=0Atoute copie=2E Le courrier > > =E9= > > lectronique n'est pas garanti s=E9curitaire=0Ani exempt d'erreurs=2E Les > > me= > > ssages pourraient =EAtre intercept=E9s,=0Acorrompus, =E9gar=E9s, > > retard=E9s= > > ou contamin=E9s par des virus=2E=0AL'exp=E9diteur n'est pas responsable de= > > ces risques=2E > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > -- > Art S. Kagel > Oninit (www.oninit.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions and > do not reflect on my employer, Oninit, the IIUG, nor any other organization > with which I am associated either explicitly or implicitly. Neither do > those opinions reflect those of other individuals affiliated with any entity > with which I am affiliated nor those of the entities themselves. > > --0016e644d6