Error row limit after installing new version 3.4

Hello,

My team has installed the new Enteprise version 3.4 on our servers. (last version 3.4.8) When checking the execution of python scripts I get this error

Traceback (most recent call last):
File “index.py”, line 34, in
base.batch_append_rows(‘C_ABSENCE’, rows)
File “/usr/local/lib/python3.7/site-packages/seatable_api/main.py”, line 293, in batch_append_rows
return parse_response(response)
File “/usr/local/lib/python3.7/site-packages/seatable_api/main.py”, line 40, in parse_response
raise ConnectionError(response.status_code, response.text)
ConnectionError: [Errno 413] Exceed the rows limit

What I understand is that this error reflects to the row limit in SeaTable (older version where 100.000 and from version 3.4 this shoud be able to change if I understood correctly on the instructions). I have checked currently when I am running this script the we have fill rows about 1500 - 2000 and this script shoud insert about 18000 rows which is very far from the reaching the limit.

Here are the print screen from the admin view where I saw the filled rowes and also I have entered a single row to see does this number change I when i checked it again it doesnt. This problem is related to the problem that you have fixed it in version 3.4.2 (API limit rows…). Can you please look at this.




I understand that you run into a general row limit problem. But I don’t understand the details. Sorry. If you try with a more structured explanation, I am happy to check again.

Or I can answer your issue with this clarification:

The 100.000 row limit still applies in general unless you modifiy the configuration of SeaTable Server. If you want to store more rows in a base, you MUST follow the instructions here (as was also mentioned in the release notes).

Please note that upping the row limit also comes at a risk. You must respect the technical limit described on the page linked above.

Hello,

I thought that was wery clear with the print screen and everything but I will try to explain it more deeply:

As you can see on the print screen of the previous email the system information on my Database CapacityPlaning says
that I have in the database 99929 rows (but in reality I only have about 1000 rows entered, there was
much more data which I have deleted it using python scripts).

What I did for the test is next: I saw that that information of the rows is 99929 then I have entered manulay a new row in one table, after I got back to system information and there i saw that the number of rows has not been changed its the same as It was before i manuly entered the row in table. In my opinion if there is not parametrization or simular that this is a bug in the system (We have not had this problem with the version 3.3). Based on the data that I have in the databse the information shoud be around 1500 rows not 99929 (I dont see this data but the system says othervise)

As in the documentation, the limit of batch operations is 1000 rows at a time. If you have more than 1000 rows to append, split it into multiple calls. The 1000 rows in batch limit has been there for a long time since version 3.0.

For reference: System Limitations - SeaTable Admin Manual

I am very confused. You say:

99949 rows in base - 946 counted = 99003. Is your math just wrong or do I fail to grasp your problem?

In any case:

  • Please make sure that you do not overlook records because they are filtered.
  • Please post better screenshots. The last one are unusable because unreadable.

Are there any errors in the log?

Please make a manual manipulation in every table and see if this changes base’s total row count.

In the end I have created a script to count rows in each table that i have, I found that i one table had 90000 rows which was a result of of calling more scripts at the same time by using the button and when I looked better in the table there was a filter that return the result 0. After i deleleted rows from table and run the needed script again everything worked.

Glad you could fix it.

I take the liberty of removing the “bug” tag from this post, because obviously it was not a bug.

Of Course (in the end it was not a bug in the system)

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.