Search results

I can't think of a single version of Progress that ever had NO-LOCK as the default... going back to the 1980s. There is a startup parameter to set the default to NO-LOCK... but use great care in turning it on for compiles because it can easily break code. Those numbers are a crime against...

If you look in the database log file for the warm database I am pretty sure you will see that most of the time is spend processing the BI file and not the AI apply itself. Like Rob says you need to look into the hardware... especially the disks. This is a known issue with OE that I am still...

Look at the code again and make sure it isn't messing with any of the internal schema objects _File,_Field,etc. Progress KB - Modifying initial value field in template record in metaschema causes error 12376

You can hardly buy anything with a million dollars any more.... I want a billion dollars. There are several examples in the documentation and the KB.

lol wow... congrats on the new job I guess?

Happy Holidays. I am happy to say I am finally at a company that takes holiday time seriously and avoids massive implementations during Christmas and New Years :-)

So both sets are thin clients... one set is just closer network wise. You can try enabling message compression: Progress KB - How to enable message compression between the OpenEdge client and AppServer? Not swapping on Linux doesn't mean a lot without knowing how much memory you have...

Just be aware that no indexes will be used and this will read every record in the table or every record that satisfies any other (valid) where expressions.

Going to have to ask a few questions first :-) - What is your OpenEdge/Progress version? - How many network hops between the client and the server? - Are they really connecting client server or appserver? - Is it just these clients that have the issue or all of them? - What are the specs...

As someone who is working on an HA solution right now.... that is 100% true.

On Unix systems you can use the tee command to send output to multiple locations at once... OUTPUT STREAM stream1 THRU VALUE("tee myfile | lp -dkp1")

Yes you can just stop and start the database.

Sounds like the PATH for your environment is different than the PATH for the Progress session that is trying to run blat. Try using the entire path to the blat.exe and see if that works.

Like Cringer said the OE compiler only generates interpreted run time code (.r) and not a true executable. You will need to have the appropriate OE runtime licenses in place to run the code on different machines. The benefit is that code written and compiled on Windows can run on different...

Depending on your OE version you can either use the .NET calls to control an FTP client or you can use the command line FTP with scripted input... or you can script input something like cURL.

lsof is your friend... lsof yourfilename then check the return code. Lock files with the process id of the parent process is also a good idea though.

If any individual extents are larger than 2GB then large files is going to be enabled already. Total extents per area doesn't matter. You can use the proutil command to verify after a restore. Also check the ulimit for all of the linux users connected to the database to make sure they have...

Reducing the number of hops will help a little, depending on how many hops you reduce and how much data your application is pulling over. Your best bet is to get the clients and the server in the same location. Either by pulling the DB back locally or by pushing the clients out to the DB...

The order of the fields alphabetically doesn't matter for the export/import functions... if they match by the order then all should be fine. When in doubt specify the exact fields in the exact order for the export/import. For production code I almost never use the vanilla export tablename...

I guess PSC considers having the schema area in Type II low hanging fruit... I wish they would just go ahead and fix that so we can all eliminate Type I areas completely. Everything else should be relatively easy to move... obviously larger tables will take more work and longer outages. Usually...