anyone seen this before? system is 7.2, upgraded about a month ago. basically it appears drop downs that have embedded sql are not working. a similar setup on another 7.2 box works fine.
that message appears followed by SQL0843 - Connection to relational database X does not exist
SQL7022 - User *N not the same as current user
-
- Profound User
- Posts: 22
- Joined: Thu Mar 31, 2011 11:28 am
- First Name: chris
- Last Name: holko
- Company Name: genuine parts company
- Contact:
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: SQL7022 - User *N not the same as current user
Ah. It seems that someone else from your company has reported this to our support team, except that he didn't tell us it occurred when 7.2 was released.
The problem is you're running a very old version of Profound UI. You are probably the first people to ever try a release that old on 7.2. If you update to the current version of Profound UI, it will work fine.
The problem is you're running a very old version of Profound UI. You are probably the first people to ever try a release that old on 7.2. If you update to the current version of Profound UI, it will work fine.
-
- Profound User
- Posts: 22
- Joined: Thu Mar 31, 2011 11:28 am
- First Name: chris
- Last Name: holko
- Company Name: genuine parts company
- Contact:
Re: SQL7022 - User *N not the same as current user
Well on the 7.2 box some environments work, the one that does not shows in firebug the
followed by
where as the passing one does not show the SQL statement, so PUISSNVP is blank of course in the failing environment and has info in passing
Also the accompanying HTTP jobs have wonderful errors in them now
Is there any way to download older versions?
Code: Select all
AUTH
2BA773283DA2E67BE792EBF6392AA1DB0A462E64F8108F8B8276C17CA8A00991
context
rpgsp
sql
SELECT DCNAME, DCNAME FROM SYADV1 ORDER BY DCNAME
Code: Select all
{success:false,"errorId":"-99999","errorText":"Error occurred in SQL Call Level Interface","errorText2"
:"SQLPrepare()"}
Also the accompanying HTTP jobs have wonderful errors in them now
Code: Select all
Error occurred in SQL Call Level Interface
SQ99999 9 -- Argument value not valid.
The requested heap space operation is invalid.
MCH6902 0002-Attempt to free or reallocate heap space storage that is not allocated;
The pointer parameter passed to free or realloc is not valid.
C2M1212 - X'01000000': Pointer does not reference a valid heap.
-
- Profound User
- Posts: 22
- Joined: Thu Mar 31, 2011 11:28 am
- First Name: chris
- Last Name: holko
- Company Name: genuine parts company
- Contact:
Re: SQL7022 - User *N not the same as current user
thank you for the comments Scott, I am going to toss this back to the developers. I am mostly administration of systems with some development and I would prefer to have them on current version, let alone matching with their production versions.
-
- Experienced User
- Posts: 2711
- Joined: Wed Aug 01, 2012 8:58 am
- First Name: Scott
- Last Name: Klement
- Company Name: Profound Logic
- City: Milwaukee
- State / Province: Wisconsin
Re: SQL7022 - User *N not the same as current user
Chris,
The situation was this:
1) The "development" box was upgraded to IBM i 7.2, at that point Profound UI 3.3.2 stopped working. Profound UI 3.3.2 is 4.5 years old, and long past being supported by our team. We explained that, but your developer didn't understand why his production box worked, and the development one did not. He said they were both running Profound UI 3.3.2 and both updated to IBM i 7.2. The error at the time he reported this was the first one you mnetioned, the "User *N not the same as current user"
Our very first suggestion was to update to the current Profound UI. He said he wasn't allowed to do that.
2) Together with your developer, we discovered that IBM made a change to SQL that certain invocations of the SQLConnect() API would not work at 7.2, and would give the message you cite. I explained that we no longer had the old version of the source code, so I could not show him the SQLConnect() statement. In my tests, it consistently didn't work in 7.2, and that made sense because 3.3.2 was discontinuied for support YEARS before IBM i 7.2 was released, we never expected it to work on 7.2. The only mystery was why the production box was working when IBM made it clear that it would not.
3) I explained what disk objects implement SQL in Profound UI, and your developer checked the objects and discovered that they were not the same. He had some object differences between the production vs. development boxes. This explains the mystery... somehow these objects were changed on the production box. I suggested that if these changed objects made 3.3.2 work on his production box, he could save/restore them to the development box to make that also work.
4) After the save/restore of the objects, he got the "-99999 Error occurred in SQL Call Level Interface" error that you cite. This means that the data sent from the browser does not match what the server was looking for. That doesn't make sense to happen if both boxes are running 3.3.2. It means the stuff he saved/restored was a much newer version of Profound UI. Sure enough, he checked and the production box (the one that had been working the whole time) was running 4.1.4. That version is also very old and unsupported by Profound, but is much newer than 3.3.2. It's unclear why he originally told me the production box was running 3.3.2, must've been some confusion or misunderstanding, there?
At this point, he can either save/restore the remaining part of 4.1.4 so that everything on the development box is at 4.1.4, which would put the boxes at parity. Or, he can install a new copy of Profound UI (which is what we recommended from the start.) Installing the new version of Profound UI would bring things up to the point where we support it, wouild be certified compatible with 7.2 (4.1.4 is no longer suppoted and is not certified compatible with 7,2, though it worked in his tests) and would give him the latest features and bug fixes.
The situation was this:
1) The "development" box was upgraded to IBM i 7.2, at that point Profound UI 3.3.2 stopped working. Profound UI 3.3.2 is 4.5 years old, and long past being supported by our team. We explained that, but your developer didn't understand why his production box worked, and the development one did not. He said they were both running Profound UI 3.3.2 and both updated to IBM i 7.2. The error at the time he reported this was the first one you mnetioned, the "User *N not the same as current user"
Our very first suggestion was to update to the current Profound UI. He said he wasn't allowed to do that.
2) Together with your developer, we discovered that IBM made a change to SQL that certain invocations of the SQLConnect() API would not work at 7.2, and would give the message you cite. I explained that we no longer had the old version of the source code, so I could not show him the SQLConnect() statement. In my tests, it consistently didn't work in 7.2, and that made sense because 3.3.2 was discontinuied for support YEARS before IBM i 7.2 was released, we never expected it to work on 7.2. The only mystery was why the production box was working when IBM made it clear that it would not.
3) I explained what disk objects implement SQL in Profound UI, and your developer checked the objects and discovered that they were not the same. He had some object differences between the production vs. development boxes. This explains the mystery... somehow these objects were changed on the production box. I suggested that if these changed objects made 3.3.2 work on his production box, he could save/restore them to the development box to make that also work.
4) After the save/restore of the objects, he got the "-99999 Error occurred in SQL Call Level Interface" error that you cite. This means that the data sent from the browser does not match what the server was looking for. That doesn't make sense to happen if both boxes are running 3.3.2. It means the stuff he saved/restored was a much newer version of Profound UI. Sure enough, he checked and the production box (the one that had been working the whole time) was running 4.1.4. That version is also very old and unsupported by Profound, but is much newer than 3.3.2. It's unclear why he originally told me the production box was running 3.3.2, must've been some confusion or misunderstanding, there?
At this point, he can either save/restore the remaining part of 4.1.4 so that everything on the development box is at 4.1.4, which would put the boxes at parity. Or, he can install a new copy of Profound UI (which is what we recommended from the start.) Installing the new version of Profound UI would bring things up to the point where we support it, wouild be certified compatible with 7.2 (4.1.4 is no longer suppoted and is not certified compatible with 7,2, though it worked in his tests) and would give him the latest features and bug fixes.
Who is online
Users browsing this forum: No registered users and 1 guest