Hello Alex!
There may be a big releif if there is a temporary solution of at least passing a param'100 OR 1000' to SELECT function in the &build_category of $query function. This can be easily passed on from Admin_HTML.pm.
Further a simple arithmetic could also be a rescue. If &Has_new_links < 10 then it may not build at all.
Also, one can use arithmetic by less of an effort and make anathor rescue solution...
sub build_category
SELECT ..
WHERE id > $A(=1) AND id < $B(=100)
and make a loop for
$A = $B + 100
This will certainly not give time out problems and I can also adjust this option from Links.pm! In the start if I have less categories, I have the loop variable big but with the time it gets smaller.
The best suggestion I have :
1.
-Develop import-export in a way that it gives category name in the export and id in the import. This will bring a good harmony within the database. It will also get the broken numbers inbetween links, however unimportant they may be, and clean or retune them.
2.
-Once you get the categories and links out of the database, you can bring them back and it will renumber sequencially (MySQL &Last_insert_id) on its own. Simply give numbers from which to which needs to be build and you have done it. It will then be a mod "Build_only_a_category" rather than build new links only mod.
3.
-Design a simple ID selector or sensor routine (&id_select)absolutely similar to the $table.
Use this feature to reduce or remove all the build-in inherrent limitations of Links SQL for e.g.
a.
It then can recognise intellegently where and which are the Main categories for its REAL USE. There exist already a seperate table but unfortunately not fully used.
b.
Use the $id_select to build pop-ups only for their relevant sub_categories for their main categories. In such a case it will not grow into a kilometer long pop-up listings of 4600 categories as is the case at present in my add.cgi!
c.
Use this id_select to build the respective categories only.
------------------
rajani
There may be a big releif if there is a temporary solution of at least passing a param'100 OR 1000' to SELECT function in the &build_category of $query function. This can be easily passed on from Admin_HTML.pm.
Further a simple arithmetic could also be a rescue. If &Has_new_links < 10 then it may not build at all.
Also, one can use arithmetic by less of an effort and make anathor rescue solution...
sub build_category
SELECT ..
WHERE id > $A(=1) AND id < $B(=100)
and make a loop for
$A = $B + 100
This will certainly not give time out problems and I can also adjust this option from Links.pm! In the start if I have less categories, I have the loop variable big but with the time it gets smaller.
The best suggestion I have :
1.
-Develop import-export in a way that it gives category name in the export and id in the import. This will bring a good harmony within the database. It will also get the broken numbers inbetween links, however unimportant they may be, and clean or retune them.
2.
-Once you get the categories and links out of the database, you can bring them back and it will renumber sequencially (MySQL &Last_insert_id) on its own. Simply give numbers from which to which needs to be build and you have done it. It will then be a mod "Build_only_a_category" rather than build new links only mod.
3.
-Design a simple ID selector or sensor routine (&id_select)absolutely similar to the $table.
Use this feature to reduce or remove all the build-in inherrent limitations of Links SQL for e.g.
a.
It then can recognise intellegently where and which are the Main categories for its REAL USE. There exist already a seperate table but unfortunately not fully used.
b.
Use the $id_select to build pop-ups only for their relevant sub_categories for their main categories. In such a case it will not grow into a kilometer long pop-up listings of 4600 categories as is the case at present in my add.cgi!
c.
Use this id_select to build the respective categories only.
------------------
rajani