|
Hi 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 Regards, |
|
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! 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
2
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
|
What v16 build do you use (i.e. the return of "select @@version")?
16.0.0.2344