| based on revision 48 (SPS 5) of SAP HANA Studio and Database |
Maybe I'm a grouch about our software design from time to time.
Maybe I've been working in support for too long and got the 'problem glasses' still on.
I start using programs and features and rather often it doesn't take too long that I think 'oh, now that is awkward' or 'hope that this won't make it into the final release' (as I'm no developer/alpha/beta-tester, usually it DID make it into the release though...).
Important, to me at least, is to provide feedback to our development.
So, I do this, come up with alternatives, that I think are better or that I like better and then - I wait.
Sometimes the ideas get implemented, very often a more general (better) solution is found and implemented, sometimes (rather seldom) an idea is refused for some reason.
Key here is to not get frustrated over time.
For sure there are tons of ways to deal with that - one thing that works for me is to actually see how things are improved and made better.
Two examples for that:
In early revisions of HANA Studio (I just crammed out rev. 28 to make the screenshots) there was an option to drop users.
In the navigation tree you looked up the user, right-clicked on it to get the context menu - 'DELETE' and then you got this:
You might ask 'so, what, what's the problem with this?'.
Well, if you just click [OK] in this screen, the user and all objects the user owns are gone and can't be brought back without recovery of the whole database.
Due to the way HANA deals with SCHEMA and OWNERSHIP (regardless of the schema you create an object in, the owner is always the user that creates the object).
So, if you want to, say, get rid of one of the development user accounts that created a lot of code and tables and views in your product schema and you press the [OK] button above - these tables and views and procedures would be gone as well.
That's the problem. Bad pitfall.
Luckily this behavior had been improved in current revisions (SPS 5).
Now, the default selection is not to automatically drop all owned objects.
If you accidentally just click on [OK] now, the worst thing that could happen is that you loose a user account and the priviliges you set up for it. Should be easy to repair. No real harm done.
However, when you really think you want to get rid of this user account including all the owned stuff, you now also get an overview about what exactly you're going to drop.
Much better user interaction, much more 'safety' for the user.
I like that a lot.
Second example
Have you ever wanted to know where the heck SAP HANA Studio takes its information from?
I mean, you get all sorts of data displayed and sometimes this could be something you might want to use as well in your coding.
I had this rather often.
Sadly, the only option for me to figure out the SQL that was triggered by HANA Studio was the JDBC trace.
While I'm now pretty well accustomed with this trace, it simply was annoying to have to do this.
Nowadays, SAP HANA Studio is so nice to tell you.
By clicking on this fancy ℹ View log... - Button you are provided with a general SQL log that allows you to inspect the SQL, the runtime and the number of rows returned.
Small, available and useful - love it!
If there are any real advantages of an agile release model like the one we currently have with HANA, then it's exaclty this:
the very short time to improvements.
What makes me even happier is the fact, that the above really are just examples.
In fact there are many smaller and bigger improvements that had been build into HANA software and documentation.
Not sure about you, but I like seeing things getting better.
- SAP Managed Tags:
