Ajedrez - antoniomartel.com

Archivos de Categoría: English

Oracle XE, Forms 6i and a trip to Ecuador

Quite some time ago I had to deploy an application developed with Oracle Developer 6i (also known as Forms & Reports). Another public institution bestowed upon our customer, a museum, a system that would help them to catalogue, inventory and keep track of their works of art loans.

To avoid costs of licencing, as their data volume wasn’t high at all, we decided to use, as database, the free Oracle Express Edition 10g license. The cataloguing system provided required an Oracle database as storage.

But, as soon as we double clic the application icon on screen, a Windows console was opened and closed in a blink of an eye. No log, no error messages, nothing.

We thought a lot about this, we queried Oracle Metalink, web pages and forums on Oracle development but no clues at all.

Ultimately, after many Google searches, we found the solution to our problem at the Oracle Users Group of Ecuador, precisely in a Paola Pullas’s post and the comments which followed.

It seems that a patch needs to be applied to Oracle XE 10g to make it work with Developer 6i. Besides that, it was needed to set the database character UTF8, that way you could make it work with tilda and accents. So here are the steps we had to follow:

First of all, we had to ask our DBA to connect to the XE database as SYSDBA and to execute these commands to change the character set:


After that we had to apply in our Oracle Developer installation the following patch: Oracle Developer Patch 18 (number 4948577).

Hope it still helps someone. Sure there are many people out there that are still maintaining a system like this one.

Blank Totals in Oracle BI Discoverer

Another technical post. This time about how to solve the Blank Totals problem in Oracle Business Intelligence Discoverer:

I worked years ago as an EUL administrator with the Oracle Discoverer tools. We found a problem that troubled us during days: Grand Totals for some columns were empty despite of containing data that should be shown. The info was visible only when there was only one record to be added up but only an empty cell was displayed when there were more than one.

That seemed to us like a glitch or bug in this tool but it came out to be a technical decision of the tool’s designers. Let me explain:

When we got two folders related to each other as master-detail but, at the master’s folder we have got the numeric field that is going to be added up, we will get into trouble as the addition should add the master records numeric fields as many times as detail items are in our database. That’s probably not what we want.

Let’s see an example. If we got a master folder with data from official tourist guides, which includes their fares, like this:

Id.     Name       Salary
1       Pedro        2.000€
2       Juan          1.000€
3       Marta        1.500€

And if, on top of this, we have a detail folder, where we get the list of languages spoken by each tourist guide, it would look like this:

Id.     Name       Salary       Language
1           (Pedro)        2.000€          English
2          (Juan)          1.000€           English
2          (Juan)          1.000€           German
2          (Juan)          1.000€           Swedish
3          (Marta)        1.500€           German
When we create a Summary or a Total, Discoverer will show us that Pedro’s fare is 2.000€, Marta’s 1.500€ but it will display ‘_____’ (blank cell) instead of the Juan’s fare. Whether the tool showed a result, it should be 3.000€, but that is not the real fare for Juan. It is only aggregating three amounts as Juan speaks three languages.

There is a few workarounds to fix this:

  1. Maybe the amount being added should not be at the Detail folder. Should the database design be reviewed?
  2. Check if the relation between master and detail folder is 1 to 1 but it is mistakenly set as 1 to many.
  3. If everything above is right, there is one more thing that you can do: Tell Discoverer that it should add up those amounts anyway. To do so, follow these steps:
    1. Activate the ‘Show the sum of the values displayed in the contributing cells‘ option at the Discoverer Desktop settings.
    2. Set the properties AllowAggregationOverRepeatedValues and AggregationBehavior to 1 instead of 0 at the prefs.txt file that you can find in Discoverer server path $ORACLE_HOMEDiscovererutil.

This latter case should be taken being aware of what that implies. Even if it were a perfectly valid solution for the case you are trying to fix, it could exist another report, now or in future, run at the same patched server, which wouldn’t allow the administrator to see there is a problem (fan trap) and totals or summary fields are displaying wrong amounts as they are being added up two or more times (like the Juan’s fares).

How to make estimates come out the way you want (don’t fool yourself) – From Agile 101 book

Now, let’s hear a quick story about how we fool ourselves when somebody requests a quote for a job. It may have happened to you at some point.

A client has requested a quote. He has an idea in mind and wants to know how much it will cost and how long will it take. He made some calculations in his head and comments briefly on the numbers he is considering.

You arrive to your office and meet with the experts in these types of projects. After mulling it over for quite a bit you agree on how long it will take and the level of difficulty. You’ve had to do a little convincing, so they’re not so overly cautious, because after all it doesn’t look like a difficult project.

However, the final quote reached is way higher than the client had foreseen. Furthermore, if that vision were to be true, the project would not be finished by the deadline . You’ll need to reduce that estimate by at least 50%. Here’s how to do that in 5 easy steps:

You’ve done this before. You’ll be faster this time. You’ve carried out similar projects on other occasions, so you’ve surely learned from your mistakes. Also the problems that came up other times won’t necessarily happen this time (10% less). Are you sure you won’t have some new problems?
The clients said they wanted something simple. It won’t be that hard to do.

We’ll do something basic —we’ll cut on the complex stuff (10% less). The clients know their business well and it’s easy for them, but, what about you? Do you know everything you need to know about their business?

We’ll really keep a eye on costs. Some other projects weren’t monitored very closely, but this time you’ll be especially watchful of every hour spent, and you won’t let costs go through the roof (10% less).

We’ll put our best technicians on it. It’s a major project for an important client. We’ll put our best people on it (10% less, even though you don’t know whether they’ll be available on the date you need them).

We’ll make an extra effort.
If push came to shove, and we saw we were about to miss the deadline, we would ask every stakeholder to make an additional effort for a few weeks. If it’s necessary, we’ll even add some extra technicians halfway through so we can finish on time (10% less). Remember Brooks’ Law: adding extra staff to a project that’s late will only delay it even more.

And there we are. With just a little bit more work, we’ve been able to cut the initial estimate by 50%. Actually, to make the estimate match the budget, we’ve convinced ourselves that we can do the work in half the time. Sad to say, stats show that software projects take an average of 120% more time than initially estimated, and that final costs are normally 100% more than was budgeted at first.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

More on estimates – From upcoming book Agile 101

When we talk about estimating using Agile techniques, some things are difficult to accept for those of us who have been planning and calculating timing and deadlines for a few years.

We can find several techniques for Agile planning: Planning Poker, clothing sizes for task classification (S, M, L, XL, etc.) or Team Estimation Game, but, let’s face it, they’re difficult to integrate in a traditional development environment, and even harder to integrate for the clients who purchase our products (or at least, for the clients’ I’ve been able to work with).

We’re not used to seeing a team “playing cards” for a session of Planning Poker (at least, I am not used to it). I do, however, agree with the philosophy behind those techniques. I believe that they’re becoming more and more popular partly because it is necessary to dispel some myths regarding estimations. Let’s try and do just that:

We do estimates wrong

Can we do them right? To estimate is to predict how long a task will take or what materials we will need for a certain job. When we do an estimate with high uncertainty, as for example when we use the data included in a public-tender document, it’s not so much an estimation as a bet.

We need estimations—that’s obvious. We must try to predict what will happen, so we can make decisions. But unless we’ve gone through that specific task many times before, with the same team and under the same circumstances, we need to be aware that our estimates will very likely be wrong.

The more effort we put into an estimation, the closer we’ll be to reality

Estimations have a cost and that cost is high. When we don’t know every specific detail of every bit of the work we’ll be taking on, does it make sense to spend hours and hours to guess about tasks that we do not know very well? When you finish your next project, do this exercise for me. Review the time spent on every task. You’ll see that you estimated 20 hours on tasks that took you 100, and you’ll find that —with luck— you spent 20 hours on tasks that you thought would take you 100. You’ll see that there were some tasks that no-one marked as done. They simply weren’t necessary. However, hours are spent on tasks that were added later and that no-one considered necessary in the initial estimate.

We’ll estimate better with this or that technique

There are many estimation techniques but very few will be as useful as comparing the time spent in similar projects, the decomposition of the work in smaller tasks, or the conclusions of experts (it would be better if we have several of these). The fact that we’re using complex estimation techniques could give us a false sense of security about our estimate, and prevent us from striving for higher reliability. That could actually cause us higher costs (see above) where we invest time that would have been better spent doing something else (like reducing uncertainty).

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.

From Agile 101 book: Real artists ship!

Sometimes, and quite often, we delay delivering our work because we believe it is not ready. We think that we still have things to improve or correct, that we still have to work on it. More often than not, that actually comes out of fear of failure. Fear of our product meeting the market and nobody buying it, because it is not perfect, or it is not good enough.

It can also be fear of our product being criticized, because either the product or the book or our software has some typo or small bug. “I will only publish the latest blog post when there are no possible ifs, ands, or buts.” Other times it’s just perfectionism leading to paralysis.

A pottery teacher in an art school divided his students in two groups and told them what they had to do to get an A+ in his class. He told the first group that they had to do 100 vases in order to get the highest mark. However, he told the second group that to get that A+ they had to make the best vase.

This last group devoted enormous amounts of time and energy to debate and read about the best techniques for creating vases. But the best vases were actually done by the first group. They had devoted their time to practice, practice, practice and made 100 vases. Their technique had improved. It’s the same with your blog, your app or that design you’ve been thinking about. Let them meet the real users and let those users give you a thumbs up.

The world of software is full of products that were developed over years until they had every feature a client could imagine, in the way they were initially designed by their creators. Sadly when the software met the market, the market had its own ideas and needs. Very few people used every feature in those applications. Other features were heavily demanded, but none of the creators had thought about them when those products were first designed.

There is a Spanish proverb: “perfect” is the enemy of “good.” When you have a small but already useful product, ship it, show it to the public, get your first clients. They will tell you what’s missing. Learn about that, launch a second version, then a third. If you can’t get at least a small client base with your first version, maybe it is not the right time or place for your product. At least you’ll learn lots of things you didn’t know yet, and you won’t have wasted months and months of your work.

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Translation by Begoña Martínez. You can also find her on her LinkedIn profile. Proofreading by David Nesbitt.


Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información