http://www.welt.de/wams_print/article1443381/Schnelles_Internet_fuer_alle_Haushalte.html

"Wenn die Politik und die Hochschulen in Deutschland früher damit begonnen hätten, mehr Informatiker auszubilden, dann hätte auch SAP heute mehr Mitarbeiter in Deutschland."

Prepare for some ugliness using CLOB parameters in System.Data.OracleClient.

When you write provider-independent code in ADO.NET, you might find out long string support breaks with Microsoft's provider for Oracle.

SYMPTOM:

ExecuteNonQuery on your DbCommand fails with "ORA-01460: unimplemented or unreasonable conversion requested".

CAUSE:

If you prepare a CLOB parameter using DbType.String, System.Data.OracleClient has a limit of 32768 characters for the parameter value.

RESOLUTION:

Set the System.Data.OracleClient.OracleParameter.OracleDbType property to System.Data.OracleClient.OracleType.Clob.
 - AND -
Set the parameter value when BeginTransaction has already been called on the DbConnection.

If you want to avoid referencing System.Data.OracleClient, try this (at your very own risk)

I know, it's indiscrete and ugly. But it gets the job done and pays for breakfast.

Disclaimer: All information and source code is provided "AS IS", for demonstrational purposes only, without warranty of any kind, neither express nor implied, including but not limited to the warranties of merchantability, fitness for a particular purpose or non-infringement. In no event shall the blog author be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this code sample, even if advised of the possibility of such damage.

For every Windows developer GUIDs are familiar values, but they are widely used in distributed systems, too.

COM classes, interfaces, type libraries all are identified using GUIDs. And, of course, .NET had to inherit this, so every assembly, interface, class, enumeration, structure, and delegate gets its own GUID, automatically, or by means of the Guid attribute.

Then, when you think about creating an installer for your application, Microsoft Installer requires an abundance of GUID values to identify components, features and other objects it can track.

As much as anything else, all information about GUIDs can be read on Wikipedia (GUID).

What I want to talk about is GUID abuse and it has to do with converting GUIDs to strings.

Don't.

Really.

A GUID is a 128-bit number calculated so that it is globally unique after 100 nanoseconds (or so).

If you convert it to text it becomes something else. It may be formatted in a gazillion different ways. Braces, parenthesis, hyphens, spaces, lowercase, uppercase letters, GUID text encoding, UUID canonical form, all is possible. UTF-32, anyone? Due to this variability comparing GUIDs by text will become your nightmare. Ordinal compare may and will fail and culture-aware case invariant string compare is actually quite slow.

On Windows, if you use the Guidgen tool available with Microsoft Visual Studio, you will find the mysterious format which has the third group in lower case and all others in upper case hexadecimal. This doesn't help avoiding confusion.

The reason for this strange behavior is the format string resources it uses to convert the bytes to string.

I think the uuidgen tool used to do the same thing, which means it was a feature of the UuidToString function, but the version on my machine (Visual Studio 2005 SP1) does return all lowercase (or uppercase with the -c switch).

So the actual reason for the confusion may have been a Microsoft intern in the early 90's putting the wrong string resources into the SDK sample (and the Visual Studio tool).

I know GUIDs are compelling to be used as primary keys in databases. Almost anybody does it, I have received invoices with GUID invoice numbers and I've even done it myself and may be doing it in the future.

They have the fantastic property of being applicable across creators, so you can create the primary key on the client instead of going through the chore of reading back the new value from a sequence or automatic id. And GUIDs survive replication and backup/restore cycles.

Many database management systems support a native GUID type, or at least something like RAW(16). But then again, it's a pain to type SQL queries using binary data types.

So what can we do?

Have a certain amount of discipline when using GUIDs as text. Use a small char datatype like CHAR(36), set the column's code-page/collation to us-ascii, case-sensitive and choose and stick with one of the standard formats, e.g. 600e2d98-c0bf-4d6b-be53-88de15a01346 or {600E2D98-C0BF-4D6B-BE53-88DE15A01346}. Nowadays I'd prefer the first format, it is shorter and doesn't need tweaking the output of Guid.ToString.

Somebody wants us to be better than our competitor instead of being the best. That made me wonder.

Somebody recently confused Code Quality and Software Quality. That made me mad.

Somebody said software developers should get out of fairyland and face the real world. That made me sick.

Famous people say software developers are most commonly bad at what they do. That trips me over the edge every time.

Guys, bad software is not the software developers fault. (Bad code is.)

Bad software is the fault of the people paying for it.

Don't like it? Don't pay it. Uninstall. Undeploy. Unbuy. Unmanage. Get something else. It's easy as that.

Don't start using software in the first place. If you can't articulate your needs and requirements, don't buy software to solve them.

Bad software is the fault of the software development organization not understanding the customers problem and not providing an inexpensive, viable, desirable, innovative and extensible solution to it.

Bad software is the fault of the software development management not following through with sales, marketing, architecture, development, test and support, but establishing unrealistic time boxes and unreasonable objectives.

Bad software is the fault of the software architect not taking the responsibility for it.

Bad software is the fault of the software sales and marketing not working with the customers and appropriate research organizations on identifying the primary needs and requirements, not generating feasible and innovative solution ideas and non-functional requirements, and not imagining that there are human beings in front of the screen.

Do we even know who the customer is, anyway? The girl using the client front-end rather wanting to go shopping? The poor chap in the server room desperately trying to maintain system integrity? The overworked IT manager? The parsimonious finance guys? The special-interest influenced government creating new laws, regulations and other bureaucrazy compliance obstacles?

How in the world should a software developer working in a larger organization be able to balance the needs of those persons in a completely orthogonal field just by generating code for ever-changing runtime environments while maintaining sanity and having a fulfilled work-life-balance?

If you've figured this out, let us know how to fix the break in the time-space-continuum.

Hardware developers have it easier.

Matter doesn't change that often. The laws of physics and chemistry are quite stable and are not too much influenced by politics or psychology.

How often is there a fundamentally new technology, like say nano-technology, and how much time has it to penetrate the industry? How much time would you grant a mechanical engineer to go from zero to full-speed on such a change?

The benefits of a hardware improvement are easy to see and understand. Your new pump pumps more smoothly and is longer lasting and needs much less maintenance? Congratulations! By the way, do you care that I just refactored 42 class definitions so that they are easier to change when we need to?

Hardware can much more often be built bottom-up than software. But most of today's software is not top-down, at least not in the way it is used.

Abuse is a phenomena much more likely to happen with software than with hardware. If you use a hammer to comb your hair, it's gonna hurt. Why do you think using Excel for calculating payroll doesn't?

Hardware is easier to make stronger.

If it breaks, send someone to weld another mount to it or use stronger material for the next charge.

No matter how hard you try, software can't be made unbreakable. Really. Trying to fix software quality by sending software developers to the customer is like sending a pig to a vegan kitchen to learn taste.

Honestly, the software chasm is vast, I'm having to learn. I want to write software. You don't want to use it.

So don't blame the developers for bad software quality. Blame yourself.