As a general rule, we discourage people from setting the "Max Fields per Database Table" option to higher values. Database tables can only hold a certain amount of information in them. As such, the software will split the collected data fields across multiple tables so that more information can be collected in the survey than a single table could handle.
The "Max Fields per Database Table" option simple lets the software know where to start storing other fields on a new table.
For example, if you are collecting 600 data points in the survey and "Max Fields per Database Table" is set to 300, the data will be stored across two tables:
Table 1 will contain 300 data fields, and Table 2 will contain 300.
If you set "Max Fields per Database Table" to 100, the data will be stored across six tables, with each table containing 100 data fields.
As such, increasing the "Max Fields per Database Table" option to 600 will try to put all the data fields into a single database table. This can cause errors because the database engine may not be able to store that much data in a single table - especially if the data fields you are collecting are larger (such as open-end text responses).
From a usability standpoint, there is very little difference this option will make on the survey itself; when you download the data, the software will join all the data from across the database tables into a single .csv and present it all together. From a database performance perspective, spreading the data across multiple tables does mean querying that data requires more transactions, or more complex transactions, but to this point, we have never seen this impact a survey negatively enough to be anywhere close to significant.
Occasionally, when uploading a survey to a server, a user might see an error from the database that has something to do with data fields or capacity or tables being unable to be created. The solution to this is almost always decreasing the "Max Fields per Database Table" option, not increasing it.
So, in short: No, the software does not allow for a higher "Max Fields per Database Table" setting, but it is by design. There are very few reasons why it would ever be advantageous to do so.