Search results

Not an Oracle restriction by any means. Maybe a policy on their side or misunderstanding. One user to actually create/maintain the schema holder that can be turned off when not in use will usually resolve most policy issues. From a strict security/audit perspective the normal users should not...

You need to import the cert into Progress... using certutil. The Progress KB has several entries explaining the exact process.

By export... do you mean import?

Pro2 Replication Suite | Progress to SQL Replication | BravePoint Pro2SQL will be your best/easiest bet. Otherwise you will be writing and maintaining your own code to do the replication.

Not too shocking... just pointing out how basic that task is. I am sure we all have run into Progress developers/dbas that hold the position but not the skills.

If they don't understand they aren't an Oracle DBA :-) If they have reservations about allowing that level of access.. I usually had one user to create/maintain the dataserver and one or more users with much more limited rights to actually run the code.

You need a TNSNAMES.ORA in your Oracle client directory tree. Tnsnames.ora - Oracle FAQ Once you have that set up you can verify by using running sqlplus to connect to the Oracle instance.

Strange but not amazing... I know I have never used the TT Maint for production/meaningful code. I suspect I am in the majority :-) Not sure if there is an option or bug for that but you could check the KB to see.

Temp-Tables do not belong to databases... they are client objects and cannot have a database prefix. Just like variables or widgets.

You need to make sure that the Oracle connection info is correct. Can you connect from SQLPLUS to the Oracle database? Are you planning on doing local connections or remote connections? I would suggest remote since you have much better control over the configuration. I find the OE...

Download ProTop and see what is happening from a database IO perspective. If you can find the problem queries run an explain plan to see if the path is anywhere near correct.

Outside of the basics of appserver configuration.... a huge percentage of actual performance and perceived performance is going to depend on your code. Make too many calls to satisfy an application function and you will have issues with latency. Read too many records from the database or over...

You should be able to see the previous versions of the code by right clicking on the object and looking at the history. I am sure there are some API calls for this too but don't have RTB handy at the new job. Once you have the right version you can assign the correct versions of the objects to...

Short answer.... you will have more agents. Longer answer... it depends heavily on your environment and your application and your OE license counts. Nothing bad could happen, nothing good could happen or some mix of the two. If you run out of memory or allow more users to run more bad code it...

Look up dynamic queries (CREATE BUFFER, CREATE QUERY and the buffer methods like FIND-FIRST,FIND-UNIQUE,etc)

Agree with Rob... 32 bit is even more reason to use B2.

In that exact scenario the customer and suppliers (and other important lookup/dimension data) should be in the alternate buffer pool. That is the only way to guarantee they don't get flushed by other activity. With or without lruskips records are going to be flushed from the primary by large...

If you are doing range matching on A then like Rob says not much is going to help.... as soon as you stop using equality matches in an index the database stops using the rest of the index columns, Either you need to move column A down in the index (with compound indexes) or you need to change...

If you are only doing equality matches then choice one will work... as soon as you implement a range of any kind then choice 2 would work while choice 1 would cause excessive reads and bad index selection.

No way for us to tell what the root issue is... but you could try copying the file again and see if the issue goes away. Also look into the scripts.