Bug into RestoreProgressEventArgs class - PgSqlDump problems

[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 :

Any ideas to make it work properly ? Or just it is impossible to restore database saved by the same tool?

[Shalex]

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.

If possible, please upload your test project with the dump for reproducing the problem to some file exchange server and send us download link.

When 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.

[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.

[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.

[Feneck91]

Any workaroud or fixes for these bugs ?

Thanks.

[Feneck91]

Up ! Please give a date to correct this problem ! Nobody use your database dump feature ?

[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.

[Feneck91]

It will never fix ?

[Shalex]

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.

This is the only way to solve the "Server did not respond within the specified timeout interval." issue.