Clipboard issues with Teradata SQL Assistant 12 in Citrix

General

Clipboard issues with Teradata SQL Assistant 12 in Citrix

We are using SQL Teradata 12.0 within a Citrix published desktop and having trouble with the clipboard. Data can be copied and pasted within Teradata SQL Assistant without issue. Data can be copied out of SQL Assistant to notepad, word and excel without issue.

The problem is copying data from an external application (notepad, word, excel) into the Teradata SQL Assistant. The first attempt is successful but any subsequent attempt fails pasting the original value over and over.

Any suggestions to address this issue?
Tags (2)
4 REPLIES
Enthusiast

Re: Clipboard issues with Teradata SQL Assistant 12 in Citrix

same thing applied to Taradata SQL Assistant 13.10 .net version, the copy paste constantly fail. I have to copy paste to a third party software(notepad or etc) from excel before paste back to SQLa's code editor. sometimes the resultset in SQLA need to be copy pasted to notepad before paste back to Excel... really annoying!!!
Enthusiast

Re: Clipboard issues with Teradata SQL Assistant 12 in Citrix

BTW: the issue on SQLA 13.10 does not related to citrix product.
Teradata Employee

Re: Clipboard issues with Teradata SQL Assistant 12 in Citrix

Based on the above comments these are 2 different problems.
In the 12.0 case copy/paste within SQLA is working, and copy from SQLA to another app is working. Only the copy from another app to SQLA is failing.
Since the 'paste' continually pastes the same thing into SQLA this implies that the source app is failing to copy correctly to the clipboard. (in older VB apps that was often a problem if you forgot to clear the clipboard before adding new text)

In the 13.10 comment it seems that there is a problem copying directly to/from SQLA and Excel.
I just tested with 13.10.0.3 and found that I can always copy from the Answer or History to the Query, or to notepad, but it sometimes fails to paste into Excel.
After I cleared the Excel sheet I was then able to paste again. I will need to look into this and see if maybe the 'read-only' flag, or the column formats, is getting copied over - and preventing further pastes. (if the data types do not match)
I found that I can always copy from Excel to the Query window so the problem appears to be copying TO Excel only.
Enthusiast

Re: Clipboard issues with Teradata SQL Assistant 12 in Citrix

Hi Mike, thanks for the reply. the problem is the way microsoft office manage clipboard. When you copied something from excel, you will notice that if you did not paste the content into office related product, the region you copied from is still circled by dotted line, indicating active clipboard content, then if you copy a content from SQLA, it will NOT actively override the active clipboard content managed by office application (M$ office product seems have their own clipboard management component, which can maintain a list of content been copied from office product), therefore, the content in windows clipboard you copied from SQLA will not be able to be pasted into Excel, coz the it still thinks the previous content in office clipboard is the active content to be pasted. That might give you some insight how to manage this issue.

On the other hand.. I would like to report a bug here in regarding to .NEt data Provider. ( the lastest one I downloaded from this forum). Since I started working for a consulting company now, I did not have ability to open incident directly on TD@Your Service.
the .NEt data provider 13.xx has problem when user password expired . When use SQLA 13 with .NET data provider connecting to RDBMS 12, the change password dialog shows up(as expected), but once I typed password in, the SQLA throws exceptions out while the change password session was left idle in database and disconnected. This prevent the future attempt to logon and change password . then DBA has to go in to kill the session manually so that user can use BTEQ/ODBC to change password. I remember similar behavior was encountered in JDBC earlier 2007/2008 and that has been reported by me and fixed in JDBC. Hopefully you can get this message to the right group to test it out and fix it. Thanks!