cancel
Showing results for 
Search instead for 
Did you mean: 

upgrade asa 10 to 11 32bit 64 bit

Former Member
0 Kudos
6,710

Hello all, I upgraded our test database last night from asa 10 to asa 11.0.1.2044. The upgrade was pretty easy, however when I went to restart the db server, I was told could not find ..win32\\dbsrv11.exe. In looking at the machine only the 64 bit version had been installed. I switched the startup command to ...bin32\\dbsrv11.exe. All appears to be working fine, with one interesting exception.

There is a powerbuilder datawindow with a syntax error in it, that oddly enough ran fine in 10 but 11 does not like it. So a couple of questions here. 1. Are there any issues with running a db that had been 32 bit, but is now using the 64 bit engine? I did the migration on the same machine, did it automatically convert the db to 64 bit in the migration ? 2. The sql that is in question had two periods in a column name

select crt..foo from bar crt.

The double period generates no errors in version 10 (went back and verified) however in the version 11 database it generates the error "owner 'crt' used in a qualified colun reference does not match correlation name". SQLCODE=-845. If I remove the second period in 11 it runs fine. Is this a function of moving from 10 to 11 or from 32 bit to 64 bit, both, neither ... ???

Thanks

Accepted Solutions (0)

Answers (1)

Answers (1)

MCMartin
Participant

The SQL Anywhere database files are totally independent of the 32/64 bitnes of the system, so the same file can be used to be run in a 32 bit database server or the 64 bit version of the database server.

I think, that the double point problem is really just a syntax problem, which you have to correct when using the 11.0.1 version of the product. It was probably not intended to access a column specific for user crt?

Former Member
0 Kudos

Agreed that the double period (..) is a syntax issue, I was just very suprised that it worked in version 10 and did not in version 11. I have already corrected the sql, and was trying to identify exactly why it worked in 10 and not in the 11 migrated database. This would help evaluate the success of the migration against our various applications before moving on to migrating production.