Today I got an email that began like this:
Congratulations on being selected to speak at the premier Oracle user group conference—ODTUG Kscope18. We had more than 1,000 abstracts submitted this year, making this selection a very challenging process.
The following abstract has been accepted for presentation at ODTUG Kscope18, June 10-14 in Orlando, Florida. If you submitted multiple abstracts, you will receive multiple emails with the status of each abstract.
Texas Racing Commission: Lessons Learned from Migrating to Oracle Cloud
I also had another presentation that got accepted as a possible alternate: Entity Relationship Modeling in the Age of Agile Development.
Hopefully I’ll see some of you at KScope in Orlando!
Remember to use code “insum” at checkout to get a discount off your registration.
Today is my first day as Director of Consulting Services at Insum Solutions! I’m really excited to be part of the Insum team. Insum has been a (the?) leader in the APEX consulting services space for many years. C2 and Insum have had very similar philosophies and execution styles. I’m really looking forward to working with the new (much bigger) team.
I’ll be speaking, but if you come, you’ll be building!
You’ve heard about the Internet of Things (IoT). C2 Consulting has put together a hands on lab where you’ll get to build an IoT thermostat from electronic components and hook it up to to REST components in an Oracle Database and then control everything from an APEX application.
You can register for the event at this link or at this url if that link doesn’t work for some reason:
This is the lab we’ll be working through and it’s pretty awesome (and award winning!): https://concept2completion.com/iotemp
Here’s some details about the when and where:
Event Timing: Friday, December 15th from 11 am to 1:30 PM
Event Address: National Instruments at 11500 North Mopac Expressway, Building C, Rooms 1S13-1S15.
Parking available in the garage for building C.
If you are in the Austin area on Friday December 15th hopefully I’ll see you there.
When I get some time I’ll try to change this into a series of blog posts, but for right now here’s a 141 page pdf file that covers the following in a step by step manner:
- Install and Oracle VirtualBox
- Create an Oracle Linux Server
- Install and Configure Oracle Grid Infrastructure for a Standalone Server (with special ‘Rich Soule’ start and stop scripts for using ACFS file systems)
- Install Oracle 12cR2
- Create a Multitenant Database
- Install and Configure Apache/Tomcat/ORDS
- Install and Configure Oracle Application Express
You can find the pdf here: Using the Oracle Cloud (or Oracle VirtualBox) to build a DBA practice environment.
It’s 15 days early (Oracle Support had said that it would be here on Feb 15th) which means that I’ll be able to start on my ODTUG presentation 15 days earlier than I thought.
Go to http://eDelivery.oracle.com to get the latest and greatest Oracle Database.
The installation documentation for Oracle APEX 5.1 has the following code in it for enabling network access from the database in a pre-12c database:
-- Look for the ACL currently assigned to '*' and give apex_050100
-- the "connect" privilege if apex_050100 does not have the privilege yet.
SELECT ACL INTO ACL_PATH FROM DBA_NETWORK_ACLS
WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL;
IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(ACL_PATH, 'apex_050100',
'connect') IS NULL THEN
'apex_050100', TRUE, 'connect');
-- When no ACL has been assigned to '*'.
WHEN NO_DATA_FOUND THEN
'ACL that lets power users to connect to everywhere',
'apex_050100', TRUE, 'connect');
You’ll notice that the username in the above is ‘apex_050100’. If you run the above code you’ll get the following:
01435. 00000 - "user does not exist"
Changing each instance of ‘apex_050100’ to ‘APEX_050100’ will address the error and you’ll be able to run the code.
Interestingly enough the new 12c APIs are apparently doing an UPPER on the passed in username because the following code works just fine:
host => '*',
ace => xs$ace_type(privilege_list => xs$name_list('connect'),
principal_name => 'apex_050100',
principal_type => xs_acl.ptype_db));
I’ve logged a bug request with Oracle Support (of course).
While upgrading a server to ORDS 3.0.9 (from ORDS 3.0.5) and APEX 5.1 I noticed the following output during the ORDS upgrade…
$ java -jar ords.war install advanced
Jan 05, 2017 3:59:43 PM
INFO: Updated configurations: defaults, apex, apex_pu, apex_al, apex_rt
Upgrading Oracle REST Data Services schema 126.96.36.199.10.54 to version 188.8.131.528.07.16
... Log file written to /home/apache/ords_upgrade_2017-01-05_155943_00336.log
Upgrading ORDS schema to 3.0.6
Completed upgrade for Oracle REST Data Services version 184.108.40.2068.07.16.
Elapsed time: 00:00:16.437
You might notice that the output has “Upgrading ORDS schema to 3.0.6” even though the version of ORDS is 3.0.9.
Of course the following query does return the right value and ORDS is the correct version:
select * from ords_metadata.ords_version;