Hello Alex! There is a bug in the add field in condition where one uses multiple mysql user with [db]s. It would try to add in a remote[db], one of the last configured remote plugin and ACTUALLY TRY TO ADD in the remote_db. If it cannot find amamber_member table, it will give a mysql error mentioning that remote_db.amember_member does NOT exists!!! It added against my wish a new field in the remote[db]. Thereafter it would not add any user record as it cannot find the newly created field in the amember_db! Well, I created a new field in the amember_db and it started adding users again.
Hi Alex! It is very disappointing to maintain fields in a remote databases and a local amember_member table, just empty table in remote, to satisfy the buggy config scripts. I am having more and more problems in adding fields. Sometimes it checks in the amember database and sometimes in the remote. For instance it says that amember_member.user6_db does not exists and stupidly forgets that the amember_member exists locally and not in remote. This is most likely due to plugins, the way how the amember_config is designed. Now, I deleted a field due to soem name changes and it did delete in the remote, which is just an empty database, but then it quirks that there is a field locally existing while creating a new one. It is a nightmare to always hunt for fields locally and remote as well as to try to satisfy the buggy configuration scripts with some possible combination of local or remote fields.... I hope to that in the next versions those bugs are removed and that the config table + scripts are better designed.
Unfortunately the amember_config field stores a blob_value for all the field configuration in a dynamic manner. Further problem is also the values are not correctly detected. The culprit is: member_fields >>> blob_value There are some values that are not correctly inserted. I confirmed this here by adding a new field in VARCHAR type and thereafter checked in the table. Both in the remote as well the local amember_member tables there is a correct configuration of VARCHAR field. However there is something missing in the blob_value which I still have to trace. Hence it is not working. I cannot just install all the fields again and again. The best option is to remove all the blob fields from the database tables, begining from the amember_config. This could be also the erason why amember is so slow in some cases. If no blob values where used, then FOR SURE the amember_config table would be chached in the mysql query cache. This would ofcourse NOT HAPPEN due to its field property as blob! I consider blob = lazy!
So following is the error: Couldn't change field type - mysql error: BLOB/TEXT column '**fieldname**' used in key specification without a key length Everywhere the field values are correct i.e. VARCHAR 255, in the local and remote.
Now that I have analysed the blob values, I think most likely it is due to having the earlier values of s:4:"cols";s:2:"20";s:4:"rows"; Now Alex, you cannot explain me that yur design of blob type of column is really necessary. In the same blob string with the above following is present: s:3:"sql";i:1;s:8:"sql_type";s:12:"VARCHAR(255)"; This cannot happen. The above error is happening because it is storing what it should not. The values are in conflict. I did create such a field but deleted as it got created erroneously. So even the values should be deleted, which did not happen, thereby causing the error and wasting hours and hours of my time. Hence the design should be changed.
For obvious erasons described above, I deleted the field from the aditional fields listings from the CP Panel. Hence there should be no traces of this field in the blob values of member_fields. However it did not allow me to delete it. How can this be true? The field showed in the CP Panel, the field is not there in the local amember or remore database. I could NOT delete the field. Howwver I manually modified the binary blob value and then it works fine. Isnt this a nice silly joke?