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
defective table TLS206 resp. TLS906
-
- Posts: 18
- Joined: Thu Aug 27, 2015 12:43 pm
defective table TLS206 resp. TLS906
TU Dortmund
-
- Posts: 440
- Joined: Thu Feb 22, 2007 5:33 pm
- Contact:
Re: defective table TLS206 resp. TLS906
Hi Tim,
I have no experience with HeidiSQL. But to check whether your data might be faulty, I would do:
I hope this helps,
Martin
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.
I hope this helps,
Martin
PATSTAT Support Team
EPO - Vienna
patstat @ epo.org
EPO - Vienna
patstat @ epo.org