One of our users has found an interesting problem. Suppose we have a parent table, in our case it is an Order table.This table has a child table called Order Tree.This Order Tree child table itself has a child table called Materials.In our application it is possible to plan an order using a task, which is available using a shortcut CTRL+1. Users can acces this task from both the Order table and the Materials table, but the functionality is slightly different for both tables, because of table task parameters that are or aren't filled.If the user is not actively selecting the Materials table, using CTRL+1 will execute the task in the Order table, even if it is not visible as list or form.Even stranger, I can execute the tasks in our Order table from the Material table, even if they are not present in the Material table. For instance, I can confirm the whole order from the Material table using the shortcut.Is this behaviour on purpose or did we find a bug?We are on the Windows GUI version
Hello all,In our program we discovered that a column should have been mandatory but was not selected to be in the SF. This has been fixed in a later version by simply making the column mandatory, and we wanted to try to use the Data conversion functionality to fill in the missing data. The following expression has to be used for filling the column, and this has been selected in the SF as well;isnull(t1.calculatie_soort,(select ws.standaard_calculatie_soort_id from waarde_standaard ws))However, when generating the code for this upgrade, we found out that the SF generates a faulty statement when inserting the data from the renamed table; t1."product_type" as "product_type", t1."calculatie_soort"(isnull(t1.calculatie_soort,(select ws.standaard_calculatie_soort_id from waarde_standaard ws))) as "calculatie_soort", t1."per_1_of_100" as "per_1_of_100",As you see, unchanged columns are fine, but our change column "calculatie_soort” now causes an error, as bot the "normal” co
We have multiple clients using our software, and some of them may have a different version in production than other. In some cases, there is the need for data conversion because of new functionalities or restrictions. We encounter some risks when upgrading from different versions i.e. we have one client that is currently on version 6.300 and one on a slightly higher version 6.301.We developer our conversion script for version 6.400, and place it in a certain folder. However, this come with some risks and we would like to manage our conversion scripts in the SF.We already use the UPGRADE code group for scripts that have to be executed every upgrade, but in this case we need a script that will be executed in every upgrade that encapsulates version 6.400.So in our examples, an upgrade from version 6.300 to 6.400 should have the script, but also from 6.301, or even if we skip version 6.400 and go straight to a 6.401.The UPGRADE code group can be used to manage data conversion scripts for s
We are looking to upgrade our TW software to version 2022.1, and during my tests I encountered some performance issues while synchronizing our latest version. Our performance monitor pointed towards the function look_up_chain_granted. This function is called around 1.5 million times, as our application contains a high amount of Roles. At 1.25ms per execution this could take a very long time. The performance index suggested adding the index stated below and this decreased the avg execition time to 0.075ms, which helped with decreasing the total sync time from almost one hour to just ten minutes.I would suggest Thinkwise take a look at this suggestion as it has helped us very much.CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname, >] ON [dev_sf_upgrade_test_2022].[dbo].[ref_col] ([project_id],[project_vrs_id],[target_col_id]) INCLUDE ([abs_order_no])
The database of our SF is starting to become a little too big for our liking, and this may result in slower upgrades whenever Thinkwise releases a new version. When we first started using Thinkwise software, we were told it was not necessary to delete any old versions, as one could lose some history in for instance the template code history. I was wondering whether there are any updated best practices or recommendations from Thinkwise on how old project versions and branches can managed.
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
