Custom Fields no longer searchable in 1.9.12 after migration

[andrewleepy]

I upgraded my TestLink version from 1.7.5 to 1.9.12 by:

1) Downloaded and extracted a new TestLink from 1.9.12 and put it on a new machine
2) Then apply the keys from custom config files from original testlink and copy them over to new testlink
3) Back up original database and then manually apply each database migration step from following to original database:

Execute install/sql/alter_tables/1.8/mysql/DB.1.2/db_schema_update.sql
Execute install/sql/alter_tables/1.8/mysql/DB.1.2/z_final_step.sql
Execute install/sql/alter_tables/1.9/mysql/DB.1.3/step1/db_schema_update.sql
Execute install/sql/alter_tables/1.9/mysql/DB.1.3/stepZ/z_final_step.sql
Execute install/sql/alter_tables/1.9.1/mysql/DB.1.4/step1/db_schema_update.sql
Execute install/sql/alter_tables/1.9.1/mysql/DB.1.4/stepZ/z_final_step.sql
Execute install/sql/alter_tables/1.9.4/mysql/DB.1.5/step1/db_schema_update.sql
Execute install/sql/alter_tables/1.9.4/mysql/DB.1.5/stepZ/z_final_step.sql
Execute install/sql/alter_tables/1.9.6/mysql/DB.1.6/stepZ/z_final_step.sql
Execute install/sql/alter_tables/1.9.8/mysql/DB.1.9.8/step1/db_schema_update.sql
Execute install/sql/alter_tables/1.9.8/mysql/DB.1.9.8/stepZ/z_final_step.sql
Execute install/sql/alter_tables/1.9.9/mysql/DB.1.9.9/step1/db_schema_update.sql
Execute install/sql/alter_tables/1.9.9/mysql/DB.1.9.9/stepZ/z_final_step.sql
Execute install/sql/alter_tables/1.9.10mysql//DB.1.9.10/step1/db_schema_update.sql
Execute install/sql/alter_tables/1.9.10mysql//DB.1.9.10/stepZ/z_final_step.sql
Execute install/sql/alter_tables/1.9.11mysql//DB.1.9.11/step1/db_schema_update.sql
Execute install/sql/alter_tables/1.9.11mysql//DB.1.9.11/stepZ/z_final_step.sql
Execute install/sql/alter_tables/1.9.12mysql//DB.1.9.12/step1/db_schema_update.sql
Execute install/sql/alter_tables/1.9.12mysql//DB.1.9.12/stepZ/z_final_step.sql

Then do a database dump and import it to mysql on new machine.
Start up testlink and things look ok after migration except:

1) Custom field on original test case no longer searchable (new test cases work fine)
2) Also, notice that new test case id now increment by one instead of two.

Just wonder if above manual database migration step is correct, and whether it would
cause the search by Custom Fields to fail.

Thanks!

[fman]

Too many things has changed since a very old version like 1.7.5.
If I'm not wrong now (but you can check doing some test) Custom Fields are linke to test case version not to test case.
This can be what generate issue on search.

>> ... new test case id now increment by one instead of two.
it is not clear what are you talking about, because test case id are generated as usual.

IN ADDITION you have to follow instructions for each version, because till some versions YOU NEED TO USE THE INSTALLER to do the update/upgrade, and not just simply run the SQL Queries.

Best thing to do is follow what installer suggest and what is written on README of each release

[andrewleepy]

Thanks for the reply.

You are correct and I have checked and indeed the Custom Fields are now linked to TestCaseVersion instead of TestCase.

I have some general questions about the upgrade procedure:

1) From some previous posts, I have read somebody who wanted to

a) upgrade from 1.6.x to 1.8.5:
The suggestion was to:
you can not do together. Please migrate from 1.6.2 > 1.7 > 1.8 > 1.9. in this order

b) upgrade from 1.7.4 to 19.2
The suggestion was to:
1.7.4 -> last 1.8 -> 1.9.2

So for my case, if I want to migrate from 1.7.5 to 1.9.12, the correct path should be:

1.7.5 -> 1.8.5 -> 1.9.3 (using auto installer) <--- I don't need to do 1.7.5 -> 1.8.0 -> 1.8.1 -> ... -> 1.8.5 one by one, and can skip right to 1.8.5 and then 1.9.3, right?
1.9.3 -> 1.9.4 -> 1.9.5 -> ....1.9.12 (using manual mode = apply source code change + run schema_update.sql)

In general, for above procedure, after I finish each intermediate step, do I need to bring up TestLink and login and so do some stuff before shutting it down and proceed to next step?

2) By the way, if I follow upgrade/migration for each step and apply one by one like above, would it update the correct association
for Custom Fields from TestCase to TestCaseVersion? Or I have to manually change the database entries myself?

Thanks in advance!

[fman]

>> in general, for above procedure, after I finish each intermediate step, do I need to bring up TestLink and login and so do some stuff
>> before shutting it down and proceedto
>> next step?
It's a good thing login after each step and do some quick checks on several features

>>2) By the way, if I follow upgrade/migration for each step and apply one by one like above, would it update the correct association
>>for Custom Fields from TestCase to TestCaseVersion? Or I have to manually change the database entries myself?
My idea is that association will be fixed by the installer when there is possibility to run upgrade.

[andrewleepy]

I have so far tried this upgrade path 1.7.5 -> 1.8.5 -> 1.9.3 (using auto installer to do schema upgrade and data migration) , and skipped the intermediate releases.

I then started TestLink 1,9.3, and I can see the Custom Field is now associated with TestCaseVersion instead of TestCase as you expected.

However, I now encounter an issue with the test case ID:

When I log in, now all the test case ID seems to include a truncated string of the project name.
For example, if I have project name Telephone System, the test case id now looks like Telephon1234. However, when I search the id using Telephon1234, it failed.

This happened to all other projects, where the test case id includes at the start part of the name of the project.

I suspect this has to do with the table prefix....when I do the upgrade of 1.9.3, there is optional table prefix in the GUI (which I left empty).

<Questions>
1) Do I need to give the table prefix a value when I do the upgrade, and what value should I put there.
2) If I continue on to do the upgrade from 1.9.3 to 1.9.12, do I need to download the install kits for version 1.9.4, 1.9.5, 1.9.6, and etc to 1.9.12, or I can simply download 1.9.12 and just
directly apply the schema_update_sql in the alter_table directories for 1.9.4, 1.9.6, 19.9, 1.9.9, 1.9.10, 1.9.11, and 1.9.12?

Your advices are very much appreciated! I have to take over this upgrade task from some coworker who left, and as you can tell,
I am still a bit confused over the proper procedures...

[fman]

>> I have so far tried this upgrade path 1.7.5 -> 1.8.5 -> 1.9.3 (using auto installer to do schema upgrade and data migration) , and skipped the intermediate releases.
skipping is not a good thing.
Your situation is far from easy (because your version is too old) and if your choice is not following the stablished procedure helping you become very difficult and time consuming.

Please do not guess => table prefix has nothing to do with PROJECT PREFIX used to create TEST CASE EXTERNAL ID.

Before returning here for help try to be sure you have followed 100% instructions provided on README and on forum. Creating this info has required time.
Doing thing in the slow but required method is not going to require hours.