Page 1 of 1

Bug into RestoreProgressEventArgs class - PgSqlDump problems

Posted: Thu 14 May 2020 09:56
by Feneck91
Hello to everybody.

As I indicate into this post 2.5 years ago, there are some problems with RestoreProgressEventArgs when a database is restored.

I suggest changing Offset and Length properties of the RestoreProgressEventArgs class from Int32(int) to Int64 (long) : It has been done by your developers team.
Do you test it on big database restauration ? May be not.

Now, when restauring big database (21 Go of text dump for only a part of our database that I'll be need in the future) I have several problems :
  • The RestoreProgressEventArgs.Offset field grow up and when it become big, it goes back on small number, may be in internal code some interger (and not long) are used and there are overshoot.
  • When creating foreign keys on Table that contains millions of rows, I have this exception.
    Some sentences are in french : Image
Any ideas to make it work properly ? Or just it is impossible to restore database saved by the same tool?

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Posted: Wed 03 Jun 2020 16:52
by Shalex
Feneck91 wrote: Thu 14 May 2020 09:56The RestoreProgressEventArgs.Offset field grow up and when it become big, it goes back on small number, may be in internal code some interger (and not long) are used and there are overshoot.
If possible, please upload your test project with the dump for reproducing the problem to some file exchange server and send us download link.
Feneck91 wrote: Thu 14 May 2020 09:56When creating foreign keys on Table that contains millions of rows, I have this exception.
Try increasing the value of your Default Command Timeout connection string parameter. 0 indicates no limit.

There is a workaround for both issues: iterate through the collection PgSqlScript.Statements and execute statements one by one. A sample is available at https://www.devart.com/dotconnect/postg ... ments.html.

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Posted: Thu 04 Jun 2020 10:50
by Feneck91
Hi Shalex,

I hope you are fine.

The database is very big and contains company secret's informations. I cannot give you the database.
Create one with lots of data with test project will take too much time to develop.

I think you should have big databases in your dev environment to test your drivers, isn't it?

I don't know how to help you more.
Any idea?

Stéphane.

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Posted: Fri 05 Jun 2020 21:18
by Shalex
Please iterate through the collection PgSqlScript.Statements and execute statements one by one: https://www.devart.com/dotconnect/postg ... ments.html.

We will try to reproduce the issue you have encountered and notify you about the result. There is no timeframe at the moment.

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Posted: Mon 17 Aug 2020 14:34
by Feneck91
Any workaroud or fixes for these bugs ?

Thanks.

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Posted: Mon 14 Sep 2020 08:16
by Feneck91
Up ! Please give a date to correct this problem ! Nobody use your database dump feature ?

Re: Bug into RestoreProgressEventArgs class - PgSqlDump problems

Posted: Thu 24 Sep 2020 15:36
by Shalex
The fix of the Int32(int) issue will not solve the "Server did not respond within the specified timeout interval." problem. The later one occurs when the server itself drops connection after some period of activity or when there are network problems.

PgSqlDump.Restore() doesn't include the failover logic because it has to work with the connection object that was provided to it only.

Why don't you want to iterate through the collection PgSqlScript.Statements and execute statements one by one? Refer to https://www.devart.com/dotconnect/postg ... ments.html. This approach allows you to implement your own failover mechanism. If pgStatement.Execute() fails within try...catch, you can reexecute the same statement with the new connection and move further.