Page 1 of 1

defective table TLS206 resp. TLS906

Posted: Sat Jun 23, 2018 1:26 pm
by Tim Grünebaum
Hi,

the topic nearly summarizes my problem completely.
Almost every query I start containing table TLS206_PERSON results in a crash of my SQL server.
I am using PATSTAT 2018 spring and HeidiSQL as a server.

Has anyone experienced a typical problem with any kind of table and what could be a solution?
Maybe the table is indeed defective as my PATSTAT version is quite new; or there was a malfunction during the download, unzipping, table creation etc.
The problem will - if any exists - lie in table TLS906 as the table creation queries load table TLS206 with TLS906 data as both are nealy the same.

Best regards

Tim Grünebaum

Re: defective table TLS206 resp. TLS906

Posted: Mon Jun 25, 2018 7:26 am
by EPO / PATSTAT Support
Hi Tim,

I have no experience with HeidiSQL. But to check whether your data might be faulty, I would do:
  • Count the number of rows in your TLS206_PERSON table. According to the documentation which is part or the delivery there should be 56 611 335 rows.
  • Run your query with a native DB client for your MySQL , Postgres or whatever DBMS you are using. So you are bypassing HeidiSQL and can check whether the problem is in the data or with HeidSQL.
  • Compare the SHA values of the respective CSV files with the SHA values provided by the EPO download server, to check whether there was an issue with the download of the CSV files.
  • If the CSV files are OK, re-load them and re-create the tables.
A hint: Person tables contain names, which can contain any character. Some systems do not handle UTF-8 correctly. So this might be a source of issues. We experienced e.g. for using MySQL: You must select character set uf8mb4, because MySQL's character set utf8 is restricted to 3 bytes (cf. https://dev.mysql.com/doc/refman/5.5/en ... f8mb4.html)

I hope this helps,
Martin