Oracle related rants (and lots of off-topic stuff)…
In today’s video we’ll give a quick demonstration of using the APEX command-line export utility.
The video is based on this article, which includes more examples, and Windows-based examples also.
The star of today’s video is my daughter Heli “Hell-Squirel” Helskyaho. Make sure you check out the cloud forming a Pikachu tail above her head! 🙂
Cheers
Tim…
In today’s video we’ll give a quick demonstration of deploying an APEX application using the SQLcl implementation of Liquibase.
I Know what you’re thinking. Didn’t I do this video two weeks ago? The answer is yes and no. This video is very similar to the Liquibase video I did two weeks ago, but that was using the Liquibase Pro client. This video uses the SQLcl implementation of Liquibase, and more specifically the runOracleScript tag to achieve the same thing.
The video is based on this article, which has an example of deploying an APEX workspace and an APEX application.
If you are new to Liquibase and SQLcl, you might find it easier to start with these.
The stars of today’s video are the offspring of Jeff Smith. I had been annoying Jeff on Twitter DMs while he was meant to be on holiday, so I agreed to pay him back by turning his children into international megastars. I take no responsibility for how they handle the fame! 😉
Cheers
Tim…
Today’s video is a quick demonstration of deploying an Oracle Application Express (APEX) application using Liquibase.
The video is based on a new article of the same name, which covers the deployment of both APEX workspaces and APEX applications using Liquibase.
Here’s some other content you might find useful.
The star of today’s video is Jorge Rimblas, making a welcome return to the channel, along with some serious reverb. 🙂 Last time we saw Jorge was in a boxing gym, and his daughters have also taken the spotlight for one video.
Cheers
Tim…
Today’s video is a quick demonstration of using the APEX_DATA_PARSER package to convert simple CSV, JSON, XML and XLSX data into rows and columns.
If you want the copy/paste examples and the test files, you can get them from this article.
Yet another reason why you should always install APEX in your databases.
The star of today’s video is Kosseila.HD, also known as BrokeDBA, complete with sun glasses, basket ball and a rattling watch. 🙂
Cheers
Tim…
About 2 days ago we saw the announcement of the release of APEX 20.1.
I normally set myself quite an aggressive timetable to get new APEX releases to production. So much of what we do lags behind the curve, to the point where I just want to see it burn, so when I get the opportunity to force the issue, like I do with APEX, I do.
In my typical fashion I move all my builds to the latest release and kind-of forget any prior release ever existed. As result, you will see all my Vagrant and Docker builds have been updated to use APEX 20.1, along with updates of OpenJDK and Tomcat.
The basic installation is the same as always (here), so there is no drama there.
Next week I’ll start upgrading a few of our development environments, and check everything looks OK. Assuming I hit no problems, it will be full steam ahead. Fingers crossed.
The new features are always a big draw for most people, but I tend to start by looking at the deprecated features and desupported features.
As far as the new features in the announcement, here are my initial (and uneducated) thoughts.
There are a bunch of other things in the release notes that sound interesting, including remote application deployments using REST Enabled SQL, but I’ll leave you to discover those for yourself.
It’s early days, but this looks like a really nice release… Again…
Cheers
Tim…
I recently had a bit of a rant on email about the current state of Shadow IT at work. Typically, we don’t know it is happening until something goes wrong, then we’re called in to help and can’t, mostly because we don’t have the resources to do it. My rant went something like this…
“This is shadow IT.
Shadow IT is happening because we are not able to cope with the requirements from the business, so they do it themselves.
We need to stop being so precious about tool-sets and use low-code solutions to give the business the solutions to their problems. This allows us to develop them quicker, and in some cases, let them develop their own safely.”
We are not a software house. We are not the sort of company that can take our existing staff and reasonably launch into microservices this, or functions that. In addition to all the big projects and 3rd party apps we deal with, we also need to provide solutions to small issues, and do it fast.
Like many other companies we have massive amounts of shadow IT, where people have business processes relying on spreadsheets or Access databases, that most of us in IT don’t know exist. As I mentioned in the quote above, this is happening because we are failing! We are not able to respond to their demands. Why?
For the most part we make the wrong decisions about technology stacks for this type of work. We just need simple solutions to simple problems, that are quick and easy to produce, and more importantly easy to maintain.
What tool are you suggesting? The *only* thing we have in our company that is truly up to date at this time, and has remained so since it was introduced into the company, is APEX. It also happens to be a low-code declarative development solution, that most of our staff could pick up in a few days. The *only* tool we have that allows us to quickly deliver solutions is APEX. So why are we not using it, or some other tool like it? IMHO because of bad decisions!
You’re an Oracle guy, and you are just trying to push the Oracle stack aren’t you? No. Give me something else that does a similar job of low-code declarative development and I will gladly suggest that goes in the list too. I’ve heard good things about Power Apps for this type of stuff. If that serves the purpose better, I’ll quite happily suggest we go in that direction. Whatever the tool is, it must be something very productive, which doesn’t require a massive learning curve, that also gives us the possibility of allowing the business to development for themselves, in a citizen developer type of way.
It should be noted, we are wedded to Oracle for the foreseeable future because of other reasons, so the “Oracle lock-in” argument isn’t a valid for us anyway.
So you’re saying all the other development stuff is a waste of time? No. In addition to the big and “sexy” stuff, there are loads of simple requirements that need simple solutions. We need to be able to get these out of the door quickly, and stop the business doing stuff that will cause problems down the line. If they are going to do something for themselves, I would rather it was done with a tool like APEX, that we can look after centrally. I don’t want to be worrying if Beryl and Bert are taking regular backups of their desktops…
Are you saying APEX is only good for this little stuff? No! I’m saying it does this stuff really well, so why are we using languages, frameworks and infrastructure that makes our life harder and slower for these quick-fire requirements? Like I said, it’s not about the specific tool. It’s what the tool allows us to achieve that’s important.
What would you do it you could call the shots? I would take a couple of people and task them with working through the backlog of these little requirements using a low-code tool. It might be APEX. It might be something else. The important thing is we could quickly make a positive impact on the way the company does things, and maybe reduce the need for some of the shadow IT. It would be really nice to feel like we are helping to win the war on this, but we won’t until we change our attitude in relation to this type of request.
So you think you can solve the problem of shadow IT? No. This will always happen. What I’m talking about is trying to minimise it, rather than being the major cause of it.
Cheers
Tim…
I’m sure anyone who cares knows that APEX 19.2 was officially released on Friday. I did an upgrade of one of our development instances straight away and it worked fine. it’s subsequently gone to a bunch of other development instances. I’ll be pushing to get this out to production as quickly as possible.
Over the weekend I worked through a bunch of my GitHub stuff.
Vagrant : I’ve updated all my Vagrant builds to use APEX 19.2 and the latest versions of Tomcat 9 and OpenJDK 11. I was using newer versions of OpenJDK, but it seemed a bit silly, so I reverted back to the long term support release. I tried updating the base box to ‘bento/oracle-7.7’, but it kept giving me timeouts, so I’ve reverted back to ‘bento/oracle-7.6’ for the moment.
Docker : Same as above, I’ve updated all my Docker builds to use APEX 19.2 and the latest versions of Tomcat 9 and OpenJDK 11. I noticed oraclelinux:8-slim was behaving a little strangely. I thought it was a PATH issue, but I need to spend some time to understand what is happening. It seems you can’t run basic commands like dnf during the build phase. It’s probably something stupid I’m doing, but for now I’ve switched from oraclelinux:8-slim to oraclelinux:8. Just making that switch made everything work as expected.
My Docker builds within the company have gone through a similar process, so as I’m rolling out APEX 19.2 to the databases, I’m also switching the ORDS containers over to the new images. You gotta love containers!
I guess I’ll be working through all this again when the next version of ORDS and SQLcl drop. 🙂
Cheers
Tim…
Yesterday evening Hildo Haenen tweeted that the APEX 19.2 download was available. You had to use the direct file URL and you had to have agreed to the license agreement on another download, as pointed out by Markus Hohloch, for the URL to work, but you could get the software. Of course, I wouldn’t dream of doing such a thing (I totally did…).
Today it seems the download page has been updated and you can get hold of the software in the normal way.
Happy installing/upgrading folks!
Cheers
Tim…
Update: Some people may still see the download page as a 19.1 download. I guess it’s just a matter of waiting for the CDN in your region to update…
PS. First upgrade done… 🙂
“Thank you for installing Oracle Application Express 19.2.0.00.18”
PPS. Joel Kallman just made the official announcement here.
Today’s video is an example of using Vagrant to perform an Oracle database build.
In this example I was using Oracle 19c on Oracle Linux 8. It also installs APEX 19.1, ORDS 19.2, SQLcl 19.2, with ORDS running on Tomcat 9 and OpenJDK 12.
If you’re new to Vagrant, there is an introduction video here. There’s also an article if you prefer to read that.
If you want to play around with some of my other Vagrant builds, you can find them here.
If you want to read about some of the individual pieces that make up this build, you can find them here.
The star of today’s video is Noel Portugal. It’s been far too long since I’ve seen you dude!
Cheers
Tim…
With the exception of one application, which is taking a little longer to test, we’ve upgraded all our APEX installations to APEX 19.1.
I thought it would be good to share my experience of this, in case anyone is a little on the cautious side. 🙂
The vast majority of upgrades went fine. We just did the standard upgrade (install), without trying to minimise the downtime at all.
I should spend some time playing with the method for reducing downtime, but it’s hard to justify when the downtime is already short and acceptable. 🙂
One group of databases did prove problematic. It has done for previous upgrades also. The upgrades failed and I had to uninstall APEX, do a little bit of cleanup (dropping users), install it again, recreate the workspaces and redeploy the applications. It was a pain in the ass, but not difficult or time consuming. I have no idea why they failed, but as I said, it’s not the first time that has happened for this group of instances. If I had more time to play with it I’m sure I could find out, but as I know a reinstall fixes it, and time is an issue, you know what I’m going to do. Just run the scripts and move on…
As far as the applications themselves, there were no dramas. We try to keep things simple and most things are pretty vanilla, so it’s not like we are pushing any boundaries, which will expose anything. 🙂
I’ve seen some people have had problems with APEX 19.1 when it’s fronted by Apache and Nginx reverse proxies. We’ve got a mix of ORDS on Tomcat, and some things still using mod_plsql (don’t judge me 🙂 ) on OHS. This is all fronted by F5 Big IP load balancers as the reverse proxy, and we’ve not had any of those issues. 🙂
So all in all, pretty easy and what I was expecting.
Cheers
Tim…
PS. As always, I feel the need to point out we are a relatively small user of APEX, but it’s growing. Having said that, it’s installed on almost all of our Oracle databases. Added to that, I’m really aggressive about APEX upgrades, and will be even more so when the last of our systems move over to ORDS. Others may want to exercise a little more caution than me. 🙂