T
Tinco
Guest
Hi, The issue is indeed caused by the datatype mapping done by MS SQL studio for OpenEdge text fields allowing more than 4000 (unicode) or 8000 (non unicode) characters (as defined by SQL-WIDTH on the OpenEdge side). Those OpenEdge text fields are not mapped to a datatype on the MS Studio side that allow that many characters. The mapping from the OpenEdge character type is done to varchar by the MS SQL Server Management Studio those text fields should probably be mapped to varchar(max) on the Microsoft side for those large text fields. When I investigated a similar issue in the past I did not find an option to force this type of mapping to varchar(max) on the Microsoft side, Microsoft might be able to give more info about this, or implement that mapping as a product enhancement in MS SQL Server Management Studio. (this kind of mapping issue is not specific to OpenEdge) About the ODBC MaxVarcharSize (MVS) Connection option you could open an idea as described on knowledgebase.progress.com/.../P11255 and provide a link to that idea in this communities thread so that this idea can be upvoted to get more attention from our product management team. About creating views to truncate the data to 8000 characters in a column the syntax should be something like this: CREATE VIEW "TestView" AS SELECT left('note_comment',8000) as note_comment from openquery([FormNote],'SELECT "note_comment" FROM PUB."crop_note" ') ; Lowering the SQL-Width of the column note_comment from 13255 to 8000 and using -SQLTruncateTooLarge as described by Valeriy is also likely to work, the -SQLTruncateTooLarge option is available in OpenEdge 11.7 and can be used either as database startup parameter or as an ODBC option: knowledgebase.progress.com/.../Does-the-SQLTruncateTooLarge-parameter-have-to-be-used-with-a-primary-broker Hopes this help, Tinco
Continue reading...
Continue reading...