Re: Writing into Files from Stored Procedures

I know this isn't a developer's forum, strictly speaking, but you've hit one of my small retinue of pet peeves. They include touting the benefits of RAID5, placing parenthesis around the operand to 'sizeof' in C when that operand is a variable, and statements like this one of yours. Gumby, you said: "Why Java? Because the same solution would be more portable than ESQL/C." That's an old and I think spurious argument. If you are referring to the compiled shared library that results from the C or ESQL/C function(s), then yes, the interpreted Java is more portable. If you are talking about an ESQL/C app that will have to talk to multiple database engines from different vendors, then you have a point. However, what's needed here is actually pure C except for the final module that has to make the inserts/updates/deletes to the target database and that database is the same Informix database that supports the most comprehensive version of ESQL/C that there is. If you really did need to have that part be portable then write it in pure C using ODBC CLI library calls. As to the C code itself, there are C compilers everywhere including free ones and they all (except for HP's free compiler which doesn't do ANSI C) read the same source language and write out, at the very least, native machine code that operates faster than any interpreted language can. The library facilities that are needed are also standardized and ported to nearly every platform out there. Come on! Nothing is MORE PORTABLE than C! What we're talking about here is the need to write out data captured from a trigger to some external reader so that it can write it into another database after some presumably simple transformations. I can write a function to take the input from the trigger and write it out to a file in my sleep in four hours or so and have it linked into a shared library and running in the engine in another hour or less. I could also write an app to read the file(s) and patiently wait for a reliable TCP/IP connection to the remote machine to transfer the data and the catch program at the other end to take the socket connection from the client and read the data from the socket and insert it into the target server in under a day (or better yet just update the database remotely). Just add a little time to code the data transforms and we're done. I doubt that it can be written faster in Java no matter which factory you base the code on but the C version will run faster and use fewer resources and it will be portable and on any system that supports Sockets (two hours more to write it to conditionally compile to work on TLI Streams as an alternative). I've written over a hundred such applications over the last 25+ years all in C and it's all completely portable. That's portable all the way from MSDOS 2.00 to Atari, to OS2, to Windows, to MacOS (even the old proprietary OS), to Minix, to Linux, to BSD, to SystemV, to OSF1, to Cray UNIX. Java itself isn't that portable! I am very tired of hearing the portability argument as an excuse for writing fat slow resource hungry software when it's not even true. Let's base our language choices on reasonable criteria: 1. Can the language get the job done at all? 1. Do the language paradigms match the application architecture? 2. Are the facilities/features needed available or developable? 2. Can the application be written to be efficient? 1. In memory usage? 2. In CPU cycles? 3. In responsiveness? 3. Is the development process efficient? 1. Is talent available that knows the language? 2. Is the architect familiar with the language's quirks? 3. Are libraries/tools/objects available to shorten the development cycle? 4. Is the code maintainable? These and similar questions are the ones we should be asking as developers and project managers. I choose the right tool for the job and try very hard to avoid the 'hammer syndrome'. Only if we are actually developing a product that we will have to support on many platforms should the portability of the executable objects themselves be a significant consideration. I'd argue that it should not be among the first several considerations even so. If I'm AGS writing Server Studio, then object portability might cause me to write in Java. If I'm developing an app for my company to use to communicate data between two well known platforms, the option is way below my radar unless my developers only know Java. But that's a different problem. ;-) Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, May 6, 2009 at 11:31 AM, Ian Michael Gumby <im_gumby@hotmail.com>wrote: > Art, > > I mentioned MQ as an example of a non-database service that can run within > the engine. > > If the OP uses C or Java within the engine he could write his query results > out to a file. > As you pointed out, there could be a performance penalty. The more complex > solution would be to buffer the result set in to a queue to be written so > that the database doesn't get caught up in file i/o. > > Since the original OP indicated that this was to be a short term, temporary > solution, the easiest thing to do would be to write a java based stored > procedure in the engine. > Why Java? Because the same solution would be more portable than ESQL/C. > > -G > > > ------------------------------ > From: art.kagel@gmail.com > Date: Wed, 6 May 2009 10:17:36 -0400 > Subject: Re: Writing into Files from Stored Procedures > To: marc.aurele.severus@gmail.com > CC: informix-list@iiug.org > > > ER can definitely handle most ETL needs when you define the replicant. MQ > is just a data queue for IPC. Whatever app you place at the other end of > the queue will have to perform the data manipulation to insert the data in > the target. Only problem is the MQ Datablade may not be certified for IDS > 9.30, IB it first came out for 9.40. > > You are aware that 9.30 is very out-of-date and no longer supported by > IBM? You should be upgrading to 11.50 (or at least 10.00) but maybe that's > what this is all about. If so you could run the MQ datablade on the target > server and write a C UDR for the triggers to call to place data onto the MQ > for consumption by the target. More ideas.... > > Art > > Art S. Kagel > Oninit (www.oninit.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Oninit, the IIUG, nor any other > organization with which I am associated either explicitly or implicitly. > Neither do those opinions reflect those of other individuals affiliated > with any entity with which I am affiliated nor those of the entities > themselves. > > > > On