defective table TLS206 resp. TLS906

Here you can post your opinions, ask questions and share experiences on the PATSTAT product line. Please always indicate the PATSTAT edition (e.g. 2015 Autumn Edition) and the database (e.g. PATSTAT Online, MySQL, MS SQL Server, ...) you are using.
Post Reply

Tim Grünebaum
Posts: 13
Joined: Thu Aug 27, 2015 12:43 pm

defective table TLS206 resp. TLS906

Post by Tim Grünebaum » Sat Jun 23, 2018 1:26 pm

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
TU Dortmund


EPO / PATSTAT Support
Posts: 88
Joined: Thu Feb 22, 2007 5:33 pm

Re: defective table TLS206 resp. TLS906

Post by EPO / PATSTAT Support » Mon Jun 25, 2018 7:26 am

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
PATSTAT Support Team
EPO - Vienna
patstat @ epo.org


Post Reply