Error when making a field

Yeh Thanks BUT EVERYTHING LOOKS CORRECT
can I give you super admin to fix the problem? see attached
I need this fixed....
Thanks

I can not help you with database configuration issues. What configuration is needed is provided and is the defaults for any new InnoDB so they shouldn't be set to anything but what has been provided. Only your host or yourself (if you've access to database config file) can change any of that. If they can't fix it you should consider moving to a more reliable host.

I have been a member of joomlapolis for about 10 years
I just paid my membership for CBuilder and CB subs again so I can get support from this forum
My Host is Hostgator this is what my conversation with them said.

As I keep asking you and you keep telling me a story about things that don't answer my questions look.

In phpmyadmin I have file see attached says DYNAMIC

OK SEE. SO MY QUESTION IS You are saying It is important to know that the changing to ROW_FORMAT: DYNAMIC is custom, and something you will have to contact a third party to perform for you.

In phpmyadmin I didn't change anything and it says
ROW_FORMAT DYNAMIC


see attached says DYNAMIC are you saying there is another setting somewhere to change?
ROW_FORMAT: DYNAMIC

Hello,

Thank you for contacting HostGator.

If you are seeing that it is enabled for phpMyAdmin, then I would assume there is nothing else to do. The entire situation with ROW_FORMAT is not with in our scope of support. We are not able to answer question you ask if they are not with in our scope of support. The reason we have said that you would need to update the ROW_FORMAT on your own, does not mean that it is not already setup. It just means that we will not be able to assist with that settting at all. Since you have provided a partial screenshot showing the ROW_FORMAT being set to dynamic. Then there does not seem to be anything else for us to assist with going forward. All of the settings you were asking about that we can look into are already set.


????????????????????????????Please let me know if you have any further questions or concerns.
???????

Sincerely,

Kyle B.
Tier 4 Web Administrator
HostGator.com

I've spent a lot of money on this project which the team has helped me.
I have this problem that looks like it should work . But it doesn't..I need support for this It looks like it should work.

I can't even edit or add new CBuilder members.

Thanks

This isn't something we can fix even if we had access. It's an entirely database configuration problem. InnoDB limitations regarding your issue are explained below.

dev.mysql.com/doc/refman/8.0/en/innodb-limits.html
dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_page_size

innodb_page_size determines the limit you are hitting. It should be set to at least 16k of which is its default; it being set to 8k means your host has deliberately set it to that likely to just reduce storage space. Your host directly said they could not change it since it impacts the entire server. This means your hosting is not sufficient for your site. If you're using a budget hosting package then that is going to be a problem for a growing site. Your only other option is to reduce the number of fields you are using or move to a better host.

HostGator said this,
Hello,

Thank you for contacting HostGator.

Per the linked MySQL information:
innodb_page_size can only be configured prior to initializing the MySQL instance and cannot be changed afterward. If no value is specified, the instance is initialized using the default page size. See Section 15.8.1, “InnoDB Startup Configuration”.

and

The default 16KB page size or larger is appropriate for a wide range of workloads, particularly for queries involving table scans and DML operations involving bulk updates. Smaller page sizes might be more efficient for OLTP workloads involving many small writes, where contention can be an issue when single pages contain many rows. Smaller pages might also be efficient with SSD storage devices, which typically use small block sizes. Keeping the InnoDB page size close to the storage device block size minimizes the amount of unchanged data that is rewritten to disk.

The value is set to 16k, which is the default:

mysql> show variables like 'innodb_page_size';
+

---

+

---

+
| Variable_name | Value |
+

---

+

---

+
| innodb_page_size | 16384 |
+

---

+

---

+

ROW_FORMAT is set on a per table basis. Querying your server it is showing:

mysql> show variables like 'innodb_default_row_format';
+

---

+

---

+
| Variable_name | Value |
+

---

+

---

+
| innodb_default_row_format | dynamic |
+

---

+

---

+
1 row in set (0.01 sec)

As we have stated previously setting a particular row format is beyond the scope of our support, but that doesn't mean that the server is not already configured the way that you are wanting by default. The values are set as this forum is recommending already. If the table is showing that the row format is "dymanic" in phpMyAdmin then that is the format that the table is in in MySQL.

If you are seeing errors that these changes are supposed to fix then it could be helpful if you upload the dump that you are attempting to restore and provide us with the path and filename for the dump, or if you can provide us with the query we can investigate further, but we are VERY limited in what we can do when an issue is out of scope. Genuinely your best bet is probably to get a professional database administrator to make any further massive changes required for your site to the database engine.

Please let us know if you have any further questions and if you have a couple of extra seconds, there is a quick three question survey at the bottom of this email.

Best Wishes
Jon T
Senior Linux Administrator
HostGator.com


I don't know what to do?
They said this above..... it could be helpful if you upload the dump that you are attempting to restore and provide us with the path and filename for the dump,.... I'm not doing a dump or restore?????

Thanks

I'm guessing they want the query responsible for the error, which is just an alter query on the _comprofiler table done when adding a new column to the table. There's nothing more we can do for you. We can't assist with database configuration issues. There's nothing wrong with the query itself and does not appear to be anything wrong with the configuration based off confirmation from your host.

Issue is likely that you just have too many fields of specific types that are consuming too much row space. You have yet to provide how many fields you have as well so I have no idea if the limit you're hitting is even normal. I just don't see how you're hitting the limits. InnoDB uses small pointers for most column types. You should be able to easily hit 1000 fields unless you've a bunch of VARCHAR columns, which you shouldn't have as we use TEXT type on nearly all text based fieldtypes.

Try running the "Check Community Builder User Fields Database with strict column types" tool within CB > Tools. If you've an old CB database you may have a significant amount of old VARCHAR columns that can be converted to TEXT which should help with your issue.