Sparx Systems Forum
Enterprise Architect => Bugs and Issues => Topic started by: Worker on April 26, 2024, 07:21:11 pm
-
Hi,
Running a script containing a sequence of
set <newPackage> = <package>.Clone
<newPackage>.ParentID = <target parent ID>
<newPackage>.Update
fails on .Update with <newPackage>.GelLastError() returning:
Enterprise Architect (Build: 1628 - 32 bit)
Microsoft Cursor Engine [0x80040e38]
Row cannot be located for updating. Some values may have been changed since it was last read.
This error appears since upgrade from EA 13.5 to 16.2 (other staff didn't change since then).
The setup:
Windows Server 2022 Standard
EA 16.2 Enterprise Edition, 32-bit
ProCloud Server 5.1.125
ODBC 64-bit, enabled Allow big result sets, Allow multiple statements, Disable schema support, Return matched rows instead of affected rows, Prepare statements on the client
DB MySQL 8.0.33
Schema 1558
I attempted to add into the script <parentpackageOfThePackage>.Packages.Refresh and <targetParentPackage>.Packages.Refresh, hoping the package structure would update, but without success.
Any clue what could be wrong? Thanks
-
You could try to do something like
<newPackage>.Update
set <newPackage> = Repository.GetPackageByID(<newPackage>.PackageID)
<newPackage>.ParentID = <target parent ID>
<newPackage>.Update
Or if that doesn't work, use Repository.Execute to update the parentID after saving the new package.
Geert
-
Thanks, Geert.
I made a full reload and used rather the package GUID (pseudocode):
storedPackageGUID = <newPackage>.PackageGUID
<newPackage> = nothing
<newPackage> = Repository.GetPackageByGUID(storedPackageGUID)
and this seems to work.
Thanks, You saved my weekend!
-
You can wrap your script in a transaction block to manage data changes. Update your ODBC driver and consider contacting Sparx support for upgrade-specific solutions. Alternatively, try using the `Move` method instead of cloning and updating the package.
-
You can wrap your script in a transaction block to manage data changes. Update your ODBC driver and consider contacting Sparx support for upgrade-specific solutions. Alternatively, try using the `Move` method instead of cloning and updating the package.
This is complete nonsense
Geert
-
The situation remains the same - in majority of cases (I update consequently a package name and its parent package), the Cursor Engine Error still appears. I tried
- <package>.Packages.Refresh
- Repository.ReloadPackage()
- waiting 10 seconds between the steps
- discarding the newly created package object and reloading it by GUID
- using my own tool (export + import) instead of Package.Clone()
The complete case is:
- initial package structure:
<package 1>
<package2>
<template package>
Then first step is a copy of <template package> into the <package 2>. That don't fail at all.
So I have:
<package 1>
<package2>
<template package>
<new package>
Next, the <new package is renamed. This is failing in >50% cases. In EA, the package is usualy renamed, but GetLastError() contains the error
<package 1>
<package2>
<template package>
<new package-renamed>
Next, the package is moved to <package 1>. This fails in >50% cases. I don't remember, what was the ratio when the package has been moved and when not.
It's probably worth to mention, that <package1> contains ~ 1000 packages. Could that be the reason? Probably not for the renaming case, I guess.
The <package2> contains just the template in initial state.
My last resort is probably - just the retry. If an error is thrown, check the actual status by API and DB select, and if that's wrong, try it again ...
-
Are you running with direct database connection or with a connection through PCS?
From memory, we started seeing that error with v15 desktop clients when we upgraded PCS to PCS v5. But the error did not happen with v16 desktop clients.
-
The connection is PCS 5.1.125, see the thread start. Yesterday I tried to run the script from EA 13.5.1352 on another machine (hoping the problem is with EA16), but it has appeared again. Trying direct DB connection for the EA instance on server may be an option to try.
-
If you are running PCS 5.1.125 and EA 13.5.1352, your versions are out-of-synch by several numbers. From memory, the PCS version originally compatible with that version of EA was 2.x. It is possible that the error is caused by the version mismatch, the only way to test that hypothesis is to use a direct DB connection or EA 17.x.