Search results

You could always enable client logging and at least get the line number of the program that is throwing the error. Helpful for testing and debugging but not so much to prevent the error.

The bottom line on performance and index usage is... it depends. Without seeing your WHERE clauses and knowing the distribution of values in data it is impossible for us to tell you if one way would be faster or not. If you have a WHERE clause that would benefit from additional filters on the...

In addition to what Cringer said... this approach will help you determine if you have a transaction started somewhere else. You can also compile your code with the listing option to see where transactions start and end. The bottom line is: Never allow the 4GL to decide the transaction scope...

In your database directory there will be a file called <yourdb>.archival.log that will contain information about each backup taken and each AI file archived. The documentation will tell you information about each column value per record type. Other than testing your backup process there is no...

Not 100% sure the dataserver supports editioned views in 11.6... but you would need to make sure the user you are connecting as has the proper grants for the edition you care about.. either by setting the default edition for the database or by granting USE for that edition. In addition you need...

It would help to know which exact errors you are getting and an example object. If they are multi table views then you are basically out of luck from a 4GL/ABL perspective. Currently those are only supported for read operations. Unless you bypass the 4GL (FOR EACH) and call stored procedures...

Are you talking about editioning views?

Tom is right... samples over large time frames become less and less meaningful. Except to notice that horrible things have been happening to your DB over time. Which should lead to you to look at smaller sample sizes to resolve the issues.

Look at the documentation for the FUNCTION statement. It has examples of how to forward a stub definition of the FUNCTION to the actual handle of the procedure that contains the function. It would also be a good idea to read the function/procedure sections in the ABL Essentials documentation.

It isn't the calling procedure that has the issue... it is the super procedure. The super procedure needs to have a local copy of that function or a forward to the handle of the persistent procedure that actually contains the function.

Came to post what Greg did... also there are a lot of alternatives to using ACCUM and BREAK-BY. ACCUM works well in simple cases but you will get more mileage out of using temp-tables to accumulate totals. Especially as the requirements get more and more complex and/or the data gets to a point...

Just call sendmail/mail directly using OS-COMMAND instead of smtpmail.p? The vast majority of use cases don't need the full functionality of smtpmail. The mail will get queued and your mail server on AIX will take care of the delivery.

If you care that users are accessing multiple sessions at the same time either you have a coding issue or you don't understand the OpenEdge licensing. That being said.. you have to control this in your application.

Read my reply again... and the documentation. You must supply a ROWID for every buffer involved in the query in order to reposition to an exact row.

You have to supply every ROWID for the specific row... for dynamic queries you are better off using the rowid-array option and just fill the array with the proper rowids in the proper order. Documentation has the exact syntax you need.

61 billion a day is indeed quite a lot... especially for a table with that few records. For a frame of reference: I ran a 4000 user system with a 2.5TB database and we didn't have total reads (all indexes) that high per day even with tons of reports and data extracts running. Unless the...

With Type II areas it really is mostly a matter of preference.. the one exception would be indexes that grow very (your own definition) quickly. For 15 minutes on a large database those transactions aren't that bad. One system I used to admin would do several GB in 15 minutes with much larger...

Ten minutes for redo is awful.. 8 minutes for the apply isn't great either. Same advice for the BI redo as above... look into switching AI files more frequently and/or look into why you have so many transactions. I wouldn't worry about compression unless you are having severe issues...

The default has always been SHARE-LOCK... there is a -NL option you can use that changes the compile time default to NO-LOCK. If a method is specified it always uses that method regardless of the startup option. -n is the number of users.

Check out the disks that serve the BI file and make sure they are as fast as possible. I have had success in the past keeping the file system caching turned on for the BI file system but turned off for the rest of the files systems. This keeps more and more of the BI file in memory and reduces...