I wouldn't use a solution that required sql on a progress 9.x database. If you are returning a few records from a simple select statement, it might be OK, but if you try to join a table or return more than a few records it will not be reliable. We decided to export the records in a csv file...
If you are on 10.2B - make sure you are on at least service pack 6 and I think 8 was the final one released. There were some performance improvements that snuck into SP 6. You can apply a service pack without having to recompile code.
There are a lot of performance improvements between 10.1C and 10.2B06 and it isn't the complexity of a major version update.
maybe the largest improvement was to idxbuild. Often when users are looking for idxbuild parameters it's because they are trying to reduce downtime on their db.
If the medman.lg file shows the database backup on 5/4/2021 was successful you will be able to restore the database backup using the prorest utility. The medman.st file will show the database structure.
There was a SQL reporting application that was often sold with Intergy called Practice...
wow Flashback...
Look in the database log file, Medman.lg, and it will have the info on the database backup. Intergy named their database backups with a .dbk for backup or .odbk for online database backup.
You probably have a Progress version 9 or OpenEdge version 10 database there.
Originally this post was about dumping data from a Progress database medman which was used in an application called intergy. You are using a different application, but still are trying to dump data from a Progress database - C:\EPICOR\Mfgsys61\Db\mfgsys. (4235). I think you want to start a new...
memory is a bit foggy after 10 years, but I'd try creating a batch file to dump a couple tables. If it works try a few more tables, if it doesn't work look at the message produced.
With a 4GL dev license you should be able to use the data dictionary to dump the tables to files or write 4GL code to export the tables to CSV files and then load into MS SQL server. There are multiple examples on 4GL code to export to csv files.
Generate a protrace file on the user holding the lock and you will see what code is being executed. Our lock monitor would generate a protrace file on a user holding a lock when there was another user Q'd waiting. In Linux the protrace file goes to the Current Working Directory and has the PID...
seems like when reverting back to OEM 10 something is still pointing at OE 11.
"Invalid Progress version string"
Suggest turning the logging up and see what additional information is produced from running proadsv
The progress kb has an article showing the 4gl required to create a binary dump script. You can change it up to create a dump script for each area of the database.
Uggg. Even if you are stuck on Progress 9, run a dump and load to move from a 1kb block size to 4 or 8kb.
Next step would be to look at the structure file and see if everything is in the schema area...
quickly read through your previous post, guessing there is an issue with Q'd record locks.
There are a few posts on ProgressTalk that talk about scanning the _Lock table to find the connection holding a lock that has other connections Q'd behind it. There should be a few warnings sprinkled in...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.