I have a large installed base of program code that uses LS:DO to populate a SQL Server database. This code has worked great for years and recently I need to have the code be able to handle extended ASCII characters such as à and è. My code uses an LS:DO object that works with a SQL Server ODBC connection which calls a stored procedure. I have verified that the data is being read in correctly via my script. I have also modified the SQL Server columns to nvarchar but I think varchar should work since nvarchar is for unicode data. The data that winds up in the SQL table is garbage and not correct. I know that LS:DO cannot handle unicode but I thought at least it would be able to handle extended ASCII data.

Something tells me I have to use LotusScript Extensions for Lotus Connectors (LC LSX) which I find much harder to program in than the simple old LS:DO when using stored procedures.

Comment posted by Vitor Pereira02/13/2007 07:48:28 PM

Bruce,
I've moving data between Domino and DB2 on iSeries for a few years now using all sort of tools including LS:DO, my native language has all the extended characters and I never had a problem.

I am not really sure where to start. You might have to tweak the registry regarding international settings.

I don't have an SQL server here but I can try to help if you let me know some specifics.

---

Comment posted by Sean Burgess02/14/2007 05:04:27 AM
Homepage: http://www.phigsaidwhat.com/

Getting a look at the code would definitely be helpful. Without that, we're basically throwing noodles at the wall, hoping they will stick.

I looked through the forums and IBM Kbase and couldn't find any technotes about LS:DO and issues with extended ASCII.

Sean---

---

Comment posted by Bruce02/14/2007 05:25:08 AM

Thanks guys,

On Thursday I will post the code as I won't have access to it again until then.

Bruce

---

Comment posted by Stephan H. Wissel02/17/2007 11:27:24 AM
Homepage: http://www.wissel.net/

Bruce,

eventually the ODBC driver is the culprit. You might be able to tweak the settings there. I recall having a lot of trouble with it when programming LS:LCX. Switching to the OLE Provider made all problems go away. However so my knowledge you would need to bite the bullet and do LS:LCX.

If you have to rework your code, consider the following architecture:
- Have a form that captures all data you need to send to the stored procedure (can be in an auxiliary database)
- Your code only writes the data into that form (so no twiddeling with SQL in LotusScript)
- The form is linked to a auxiliary table in SQL Server using DECS. So no calling of stored procedures in Lotus Script
- The auxiliary table has an ON INSERT trigger, that calls the stored procedure.
While you need two auxiliary items and DECS this approach has the clear advantage, that very little cross domain knowledge is required.

YMMV. Ping me if u want to discuss that.
stw

---

Comment posted by 09/01/2009 12:02:27 AM

---