Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in August and this forum will be retired.


We've created an encrypted database in sqlanywhere 16. When we start the debugger in Sybase Central (16 64 bit) and hit a breakpoint and step into a procedure the complete service crashes. When we try this on a non-encrypted database it all works fine.

Does somebody has this problem also? Can somebody help us out on this?

I have the following submission ID's for this problem:

Submission ID: 2782883 reported: Fri Dec 30 11:02:06 2016
Submission ID: 2782884 reported: Fri Dec 30 11:02:29 2016
Submission ID: 2782885 reported: Fri Dec 30 11:02:30 2016
Submission ID: 2782886 reported: Fri Dec 30 11:02:30 2016
Submission ID: 2782887 reported: Fri Dec 30 11:02:31 2016
Submission ID: 2782888 reported: Fri Dec 30 11:02:32 2016
Submission ID: 2782889 reported: Fri Dec 30 11:02:33 2016
Submission ID: 2782890 reported: Fri Dec 30 11:02:33 2016
Submission ID: 2782891 reported: Fri Dec 30 11:02:34 2016
Submission ID: 2782892 reported: Fri Dec 30 11:02:35 2016
Submission ID: 2782893 reported: Fri Dec 30 11:02:35 2016
Submission ID: 2782894 reported: Fri Dec 30 11:02:36 2016
Submission ID: 2782895 reported: Fri Dec 30 11:02:37 2016
Submission ID: 2782896 reported: Fri Dec 30 11:02:38 2016

Roel Schlijper

asked 30 Dec '16, 05:27

RoelS's gravatar image

accept rate: 0%

What v16 build do you use (i.e. the return of "select @@version")?

(30 Dec '16, 06:50) Volker Barth
Replies hidden

(30 Dec '16, 07:11) RoelS

After some more research it looks like it has somehting to with the way we connect to the database. When we select "Connect with an ODBC Data source" the problem occurs. (Still only for encrypted databases)

When we select "Connect with a running database on another computer" the problem is gone!

permanent link

answered 30 Dec '16, 05:45

RoelS's gravatar image

accept rate: 0%

Since this symptom occurs during development but not end-user production, and you have a workaround, don't expect a fix any time soon.

(30 Dec '16, 07:04) Breck Carter
Replies hidden

But I still hope that this is a bug, and it is worth looking at it.

(31 Dec '16, 05:15) Vlad

Every software product has bugs that are not important and therefore not worth looking into, not when compared with the need to spend time on new features and showstopper bugs. Perfect is the enemy of Good :)

(31 Dec '16, 06:56) Breck Carter

While I understand Breck's 'not-in-production' and 'have-a-workaround' observations this does seem to have a potential concern for customers 'who may have a need to debug logic when-in-production'. My recommendation would be to contact support.

If your (effective) connection strings are identical in both cases, there should be no difference in the 2 different ways you are connecting. (You can see your 'effective' connection string by adding client side logging by adding '...;LogFile=<filename>;...' to your connection strings. With that you should be able to compare your effective connection strings to see if there are any differences. Some detail in that should help narrow this down.

One difference I am expecting is that this does have a difference in the database being used (one encrypted and one not) so something specific to the database (other than encryption) is probably contributing (possibly the version/copy of the procedure/function hitting the breakpoint ... if anything).

Otherwise I don't see any difference in the information provided. I also don't expect that encryption alone is the precipitating factor.

We in support (me at the very least) would like to get this identified. Since we are talking about debugging a debugger, identifying the cause of this would need a reproducing test case to show the problem happening; as well as access to full dumps. The submitted dumps will only be mini-dumps and those won't be sufficient for this task. You can capture a full dump but won't be able to submit it through the same mechanism (being too large). Normally you would need a support incident opened up to get that sort of thing investigated deeper.

(03 Jan '17, 11:31) Nick Elson S...
Replies hidden

Thanks for your reply. I checked the connection strings: for the odbc :

UID=ADMIN;PWD=**;DBN=MANUALENC;ServerName=MANUAL;CON='SQL Central 9';INT=NO;ENC=NONE;LOG=d:\connectionodbc.txt;Host=ontwikkelingen:2639

for the non-odbc:

UID=ADMIN;PWD=**;DBN=MANUALENC;ServerName=MANUAL;CON='SQL Central 16';LOG=d:\connectionlog.txt;ASTART=NO;Host=ontwikkelingen:2639

For the odbc the ENC and INT are automatically added by odbc but these are the default values. The non-odbc adds the ASTART=NO which is also default. Should be no problem at all in my opinion.

We'll set up a small test project and open a support ticket.

(04 Jan '17, 02:56) RoelS

Seems like we can't submit any new incidents.. it probably has something to do with licensing (maintenance expired)

(04 Jan '17, 03:22) RoelS
showing 2 of 6 show all flat view
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 30 Dec '16, 05:27

question was seen: 1,840 times

last updated: 04 Jan '17, 03:22