Re: Informix SE vs. Progress

Path: emory!swrinde!sdd.hp.com!hplabs!nsc!pyramid!infmx!aland From: aland@informix.com (Colonel Panic) Newsgroups: comp.databases,comp.databases.informix Keywords: evaluation Message-ID: <1991Oct21.092530.2658@informix.com> Date: 21 Oct 91 09:25:30 GMT References: <8339@alvin.mcnc.org> Sender: news@informix.com (Usenet News) Organization: International Brotherhood of Geeks, Local 619 In article <8339@alvin.mcnc.org> pickel@mcnc.org (Lisa C. Pickel) writes: > >I have spent the last three weeks playing with evaluation copies of >both Progress and Informix SE. I have some observations/claims-from- >literature that I would like your comments on: I guess the key question for your whole post is: why SE? OnLine is much better suited to your needs. >Maintainance: > Progress claims "...backups can be done...while the database is still > open for processing" Is this true? Can Informix SE do this? While open for *queries*, yes. Updates: risky -- you would have no coordination with transactions in progress, so you could end up getting a "snapshot" of a database while it's inconsistent. OnLine: yes. Archives, whether full or incremental, may be done on-line. > Progress claims "In the event of transaction conflicts > or system failure, a before-image file is used to automatically back out > incomplete transactions, assuring database integrity". I killed an > application in the midst of a transaction, and sure enough, Progress > automatically backed it out. Does Informix SE do this? I haven't yet > set up a situation where I could test it. SE: not automatic; the only *guaranteed* integrity would be to re-rollforward the log after restore. OnLine: yes; handled automatically if the application process dies. If the whole system dies, all uncommitted transactions are rolled back automatically as part of fast recovery. No manual intervention/commands needed in either case. > Changing tables: Progress is great for this--dynamic indexing and all. > What about Informix SE? I see the commands in the manual to change > tables, but it also mentions the need for extensive recompilation of > applications afterwards (even if fields are mentioned as tablename.*) I'm not clear what you mean by "changing tables". If you mean ALTER TABLE (e.g. add/delete columns, change column types, etc.), there is no need to even recompile unless 1) you are changing the data type of an existing column that is used in the application, or 2) you wish to utilize the new column(s) (this should be obvious), or 3) you are deleting columns referenced in the application (ditto). If you are just adding columns that you aren't referencing yet, you won't need to recompile unless you've used "select * from tablename" rather than listing out the desired columns explicitly. This is because the definition of "select *" has changed; you're getting more data back than you've identified. If your table contents are volatile, either specify the columns and don't use "*", or use DEFINE LIKE table.* and recompile affected apps when you alter tables. Where did you see this "mention of need for extensive recompilation" ? > BIG QUESTION: If you were me (a C programmer who knows next to nothing > about DBA) which would you pick and why? We don't need a 24-hour db. > We may have maybe 12 simultaneous users. Small system, right? Number of users is only one factor. Sometimes, people need to shoot huge data volumes through relatively few user processes. In your case, some of the transaction processing needs warrant OnLine use. There's really no magic minimum number of users needed for OnLine to pay off, if you need its functionality. >Security: > Informix 4GL won't let me use a variable for "user-list" in the > GRANT priv TO user-list statement. Am I supposed to write a special> 4GL routine everytime I want to add some user into the system? If > so, the data dictionary in Progress is really much better for this purpose. GRANT/REVOKE are SQL-standard constructs. In 5.0, you can create DBA-authority stored procedures which are helpful for these purposes. For now, you can either set up 4GL programs or scripts to automate things or, as I prefer, make the application(s) setuid to some special no-login user account which checks the logged-in user name and exits if unauthorized. Be sure to set both real and effective uid *before* your DATABASE statement. > Progress allows for in-code permission checking--how does one keep > unauthorized users from running Informix applications? (The UNIX > permissions may not be specific enough--unless I want to create > a hundred different little groups!) As for the application, you can check the logged-in user name and abort if unauthorized. Table access can be controlled using GRANT REVOKE. Again, using setuid to special user accounts should simplify things in the long run. >Multiple DBs: > Progress can access multiple dbs from the same application. > Informix can't. Wrong. OnLine presently allows you to select tables in non-current databases (with I-STAR, said tables can be anywhere in the network). In 5.0, two-phase commit allows updates in non-current databases as well. >Development Ease: > I can't CTRL-Z (stop) the Informix Programmers' Env (C Compiler Version)!! > Do you know how annoying this is? Works fine for me, in both i4gl and r4gl. What version and platform are you running? > Informix seems to need the edit-compile-link-run cycle while Progress > is just edit-run (and you can build binaries later). Under > Informix Rapid Development Sys, you can do edit-run I guess, but then > how can you get compiled binaries (I don't think "p-code" with a "runner" > would be as fast as compiled binaries!)? Surprisingly (to me, anyway), pcode 4GL (RDS) can be *faster* than compiled; depends on the app. Rarely is it noticeably slower (beyond a slightly longer initialization time). The problem with implementing production with RDS is that the pcode is not shared between users like the text (executable code) portion of the .4ge can be. If you have a lot of users running the same large 4GL app, RDS apps can take noticeably more memory for this reason. >Fun, Fun, Fun! >Lisa. Hope this helps. -- Alan Denney "If that honey would come back aland@informix.com we would throw such a party {pyramid|uunet}!infmx!aland Drink, and cook the prodigal son Disclaimer: I am a Toon. Fondue forks for everybody." - TMBG