lpendley@netcom.UUCP (Lou Pendley) (12/28/90)
the struggle between Oracle and Ingres and Informix continues onward. what i would like to pose to this forum, is does Fourth Dimension on the Mac have 'almost' everything the other database systems have, and more, to include: a) graphical user interface b) procedural language c) graphical data types, blobs (lookout Steve McQueen) d) complete security e) compile to binaries f) links to other database vendors, Oracle, Ingres, Informix the only limitations i can see currently are: a) not SQL standard b) not Client/Server architecture. c) does it run under A/UX, apples Unix port d) currently not portable to other O/S your input please. thank you. lpendley@netcom.UUCP.
jtt@cunixd.cc.columbia.edu (James T. Tanis) (12/28/90)
A company I do contract work for got 4D to speed up development of some in-house stuff. They ended up sending it back for a refund. The idea is nice, but it just does not work properly. There are a great many undocumented bugs, most of which the technical support people (when you could find one that knew the product!) reluctantly admitted. Also, the language is barbaric, with no notion of operator precedence, and no easy way of terminating execution of a script.I ran into some problems with stack handling, and occasionally the thing would crash without warning while in the design mode! We were using V. 2.1 - perhaps something has been fixed since then. Also, it's not very relational, if you are a purist. It _is_ nice, though, to bang out a quick user interface. -JT
joe@bram.UUCP (Joe Saladino) (12/29/90)
lpendley@netcom.UUCP (Lou Pendley) writes: :the struggle between Oracle and Ingres and Informix continues onward. what :i would like to pose to this forum, is does Fourth Dimension on the Mac have :'almost' everything the other database systems have, and more, to include: :a) graphical user interface :b) procedural language :c) graphical data types, blobs (lookout Steve McQueen) :d) complete security :e) compile to binaries :f) links to other database vendors, Oracle, Ingres, Informix :the only limitations i can see currently are: :a) not SQL standard :b) not Client/Server architecture. :c) does it run under A/UX, apples Unix port :d) currently not portable to other O/S :your input please. I had a client who spent 300k developing a system for a mac network using 4D. My evaluation of 4D a year and a half before was that 4D would not cut the mustard. The result was: database of about 100MB Single user query over network took about 40+ seconds Multi user query over network took up to 2.5 min. 4D is not a multiuser Database. 4D locks the entire database during things like reports, query, etc. Only one record can be retrieved at one time. My client is now in a lot of pain. The Macs are not doing the job and 300k in costs. They are looking at using Oracle for the Mac with 4D as a front end. Again there will be more programming costs. Funny thing is that they went with the Macs because of the graphical interface. The users have been telling the programmers to set up hot keys so they can move around the system better. When I suggest a 4GL to an organization, I recommend one that has acceptable performance and is portable to other OSs. 4D just doesn't meet the standard on a number of fronts. Just an opinion. -- Regards... __ ___ __ |__) |_ ) |__| |\/| {joe@bram.UUCP} Joe Saladino @ |__) | \ | | | | Corporation {verdix!bram!joe} -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Could John Wayne have ever taken Normandy, \ Home (503) 626-9991 Iwo Jima, Korea, The Gulf of Tonkin, and the \Office (503) 626-2772 entire Wild West on a diet of quiche and salad? \/ FAX (503) 626-5766
rad@genco.bungi.com (Bob Daniel) (12/29/90)
In article <19464@netcom.UUCP> lpendley@netcom.UUCP (Lou Pendley) writes: >the struggle between Oracle and Ingres and Informix continues onward. what >i would like to pose to this forum, is does Fourth Dimension on the Mac have >'almost' everything the other database systems have, and more, to include: > >a) graphical user interface 4D has by far the best design tools of any other db for Mac. >b) procedural language YES!!!! It even allows pointers and you can write external code resources in C, Pascal, etc. >c) graphical data types, blobs (lookout Steve McQueen) YES!!!! Picture fields >d) complete security There is user level of security to grant access to certain layouts, files, etc. >e) compile to binaries There is now a compiler that improves performance and allows running your application in stand alone form without a runtime. >f) links to other database vendors, Oracle, Ingres, Informix There is supposedly a 4D package that is available from Oracle that will allow 4D to link to an Oracle database. I haven't seen it yet. You should probably contact Oracle instead Acius. >a) not SQL standard Not a major loss unless you need to tie into other platforms. 4D's disadvantage however is that you can't do complex queriers w/out writing a procedure as you can do with SQL. >b) not Client/Server architecture. But is multiuser >c) does it run under A/UX, apples Unix port I heard it does as a Mac application. There is not an A/UX version. >d) currently not portable to other O/S No, and probably won't ever be. 4D is a good choice if you intend to keep your database on Mac. If you have the need to go across platforms, Oracle would be the logical choice. If your going to Mac Expo in January, be sure to check out the Acius booth. They have some slick new products including 4D Calc and 4D Write.
a544@mindlink.UUCP (Rick McCormack) (12/30/90)
in an article, Philip Machanick philip@pescadero.stanford.ed is replying to Joe Saladino ({joe@bram.UUCP}) about using/choosing a database and interface. He says: > A familiar story. (Only the one I know of didn't involve > 4D.) If you have anything but a trivial DB application, > getting the DB right is the major priority. Once you have > that part sorted out, you can start worrying about user > interface etc. Not that these are mutually exclusive - it's > just a matter of making sure you understand your priorities. > If you need to get a relatively big multi-user database > right, with acceptable response time, etc., you'd better > make sure the tools you choose meet these goals from the > start. Maybe the correct approach would be a pretty > interface on top of a terminal emulator, for example (rather > than a Mac-based DB) - but this could only become obvious > once you've had a first pass at the DB design. Wouldn't it be nice if the interface design tools were a part of the database? I am suggesting that the databases need an associate program that allows users to create an interface or interfaces for users or groups of users. The associate program would make use of either/or/and text and graphics (i.e. buttons, hot keys, mapping, etc.). The search functions, entry and deletion could all be implemented in multiple screen formats, and then applied to the underlying database. I know this is already a partial function of some databases, but the more we know about interface usefulness, the more we see that the interface design is not an add-on to a program, but an important part of the usefulness of the program. thus, it would seem to make sense to separate the functions of database design and database use, in order to ptimize these two very distinct functions. ______________________________________________________________ | Rick McCormack | IMAGISTICS BUSINESS THEATRE TECHNOLOGY | | Vancouver, BC | Information transfer - with a purpose. | | CANADA | ________________________________________ | | AOL: Rique | INTERACTIVE COMPREHENSIVE ENLIGHTENING | |________________|____________________________________________|
philip@pescadero.Stanford.EDU (Philip Machanick) (12/31/90)
In article <1990Dec28.223155.12781@bram.UUCP>, joe@bram.UUCP (Joe Saladino) writes: |> I had a client who spent 300k developing a system for a mac network |> using 4D. My evaluation of 4D a year and a half before was that 4D |> would not cut the mustard. [...] |> My client is now in a lot of pain. The Macs are not doing the job and |> 300k in costs. They are looking at using Oracle for the Mac with 4D |> as a front end. Again there will be more programming costs. |> |> Funny thing is that they went with the Macs because of the graphical |> interface. The users have been telling the programmers to set up hot |> keys so they can move around the system better. A familiar story. (Only the one I know of didn't involve 4D.) If you have anything but a trivial DB application, getting the DB right is the major priority. Once you have that part sorted out, you can start worrying about user interface etc. Not that these are mutually exclusive - it's just a matter of making sure you understand your priorities. If you need to get a relatively big multi-user database right, with acceptable response time, etc., you'd better make sure the tools you choose meet these goals from the start. Maybe the correct approach would be a pretty interface on top of a terminal emulator, for example (rather than a Mac-based DB) - but this could only become obvious once you've had a first pass at the DB design. So my advice on this is to try to avoid committing to a specific tool until a fair amount of the DB design is complete. In this scenario, 4D may well be a good tool for prototyping. I'm not an DB expert - just reporting a few observations based on seeing a project die as a result of doing things the wrong way round. -- Philip Machanick philip@pescadero.stanford.edu
bmug@garnet.berkeley.edu (BMUG) (01/02/91)
In article <19464@netcom.UUCP> lpendley@netcom.UUCP (Lou Pendley) writes: ...does Fourth Dimension on the Mac have >'almost' everything the other database systems have, and more, to include: > >a) graphical user interface yes, for the developer as well as tools for the end-user interface. >b) procedural language yes, Pascal-like but optimized for database operations. >c) graphical data types, blobs (lookout Steve McQueen) yes, though not quite as complete as they could be. >d) complete security adequate security for most purposes; however there is not currently a way to encrypt datafiles in DES format, which may be necessary in some installations. >e) compile to binaries yes. >f) links to other database vendors, Oracle, Ingres, Informix yes, and to Sybase as well, through DAL as well as via add-on products from TechGnosis and ACIUS. > >the only limitations i can see currently are: > >a) not SQL standard yes, but see (f) above. >b) not Client/Server architecture. not yet, though ACIUS will be showing a client-server version of 4D at the imminent Developer's Conference in San Francisco. no idea when it'll be released, though. >c) does it run under A/UX, apples Unix port yes, though there may be limitations I'm not aware of. >d) currently not portable to other O/S that's right. Hope this helps! John Heckendorn /\ BMUG ARPA: bmug@garnet.berkeley.EDU A__A 1442A Walnut St., #62 BITNET: bmug@ucbgarne |()| Berkeley, CA 94709 Phone: (415) 549-2684 | |
typ125m@monu6.cc.monash.edu.au (John Wilkins) (01/03/91)
joe@bram.UUCP (Joe Saladino) writes: >When I suggest a 4GL to an organization, I recommend one that has >acceptable performance and is portable to other OSs. 4D just doesn't >meet the standard on a number of fronts. Has anyone had experience porting FoxBase+/Mac to FoxPro on DOS environments? I understand that there is Foxbase+/PC --> FoxPro upward compatibility with a few variable problems, but I'd like to develop a system on the Mac and port it to the PC. Responses by email would be appreciated and I'll summarise if there's enough interest. -- John Wilkins, Manager, Publishing & Advertising, Monash University Melbourne, Australia - Internet: john@publications.ccc.monash.edu.au Disclaimer: IF Standard(disclaimer) THEN Applies(disclaimer) ELSIF Nonstandard(disclaimer) THEN PROBABLY (Applies(disclaimer)) ENDIF
a_dent@fennel.cc.uwa.oz.au (01/03/91)
In article <19464@netcom.UUCP>, lpendley@netcom.UUCP (Lou Pendley) writes: We have spent the last year working on a number of projects, starting with 4D using FoxBASE+/Mac extensively. We just received a copy of Omnis 5 and have decided to shift over to that for all the development we have been doing in 4D. My categorisation of these tools is: 1) FoxBASE+/Mac PROS: - dBASE III+ compatability and easy ports from Clipper etc. - the BEST report-writer around - it is as good as the best you can do with programmed reports in 4D and Omnis but is AVAILABLE TO THE USER, in "runtime-only" databases - multiple files thus you can have local files for speed and shared files on a server. This lets you build fault-tolerant systems, spread the load over multiple disks etc. - fastest in single-user mode, haven't benchmarked the new (2.01) version in multi-user but that's what it claims to improve - uses a variant of the Hypercard XCMD interface (slightly extended, eg: passing pictures) so can easily call Hypercard XCMDS - is VERY rugged, free of all but cosmetic bugs and has been very well supported - has a ROYALTY-FREE runtime binder which lets you produce cheap systems for mass distribution - has a very easy use-interface for hands-on work, as easy as Filemaker and is the BEST way to learn dBASE code - it generates the code to match your menu choices etc. - can trap window changes so you can write a true multi-window application CONS - always produces dBASE-like code which requires more work to design an interface (you can't just use the built-in form tool). Our rule of thumb is that it is twice the time of a 4D interface. Mind you, this is sometimes a benefit. - has AWFUL screen redrawing logic for scrolling areas which can give you ugly interfaces - no way to set command-keys on buttons - poor loading of a "set" of records (write a programmed loop) and limited in variable memory (foxPRO/Mac is coming!) - no security - limit of 255 characters on program lines and expressions - no hooks to anything other than dBASE files, although you could easily adapt a lot of the Hypercard externals - portability would require interface rewrites (despite FoxPro looking like a Mac, the internals are very different - wait for foxPro/Mac and FoxPro 2) 2) 4D PROS - absolute wealth of interface tools, including analog dials etc. - some very sexy externals announced (haven't seen them yet) - used to be promoted by Guy Kawasaki - good data types, easy to build an interface if you follow their rather hierarchical view of managing data - graphical approach to designing file structures good up to a point - I find the procedural language easy to use, given a Pascal background - the packaging of scripts behind buttons/fields etc. is good for reducing size of code, and building responsive interfaces. - has a great user-defined search editor CONS - is ABSOLUTELY DISGUSTINGLY BUGGY - went from 2.0 to 2.0.11 before version 2.1 which still has major bugs that can lose data (eg: a set of circumstances whic fail to save changes the 2nd time into a record!) - uses a single application file and single datafile which are both rather fragile - data size grows rapidly - the packaging of scripts etc. becomes a problem due to the lack of a global search - it can be difficult to find code. - complex screens become slow and VERY memory hungry - some of the best features (eg: user-modifiable lists, record sets) either don't work or corrupt data in multi-user mode - the user-level report-writer is a pathetic columnar effort. - it's not portable to anything!!! - enforces key disk copy protection (UNFORGIVEABLE!!!) - security is ok (group-oriented) but you can't change passwords under program control 3) OMNIS 5 PROS - interface is faster than either 4D or FoxBASE+/Mac - has a good reputation as a very strong data-engine, with good transaction handling and variety of database models - externals seem more powerful (eg: you can define your own event filter) - is supposedly directly portable to the Windows version!!!!! - complex reports are easier to create than in 4D - security appears good, multi-level - not only lets you trap window changes but appears to take care of all the context changes automatically! - includes SQL access - has a set of Hypercard externals so you can use its database from HC CONS - no way to generate database structure diagrams (although the 4D ones become unusable for a complex system) - appears to have no form of ad-hoc report-writer - like 4D, has only one data file, although you can open and close it - lacks some of the nicer 4D graphical elements (eg: dials) onscreen - still has a runtime component, the "Integrator" is expensive and we aren't sure if it lets you create true binaries - can't put command-keys on buttons (although you could write your own event filter :-) ) > > your input please. > The bottom-line is: FoxBASE for dBASE compatability, report-writer and writing cheap systems with no fuss over runtimes. (and speed). Also useful as a sort of super-Filemaker Omnis for bigger systems, with more complex interfaces and transaction support 4D possibly makes it in for VERY complex interfaces, otherwise the bin! > thank you. (All just my humble opinions of course!) > > lpendley@netcom.UUCP. Andy Dent A.D. Software phone 09 249 2719 Mac & VAX programmer 94 Bermuda Dve, Ballajura a_dent@fennel.cc.uwa.oz Western Australia 6066 a_dent@fennel.cc.uwa.oz.AU (international)
awessels@ccwf.cc.utexas.edu (Allen Wessels) (01/04/91)
In article <1991Jan3.220828.2734@fennel.cc.uwa.oz.au> a_dent@fennel.cc.uwa.oz.au writes about 4D: >- enforces key disk copy protection (UNFORGIVEABLE!!!) I usually think of key disk protection as requiring insertion of the master disk when the application is run. I just ran 4D and it doesn't.
rad@genco.bungi.com (Bob Daniel) (01/05/91)
In article <1991Jan3.220828.2734@fennel.cc.uwa.oz.au> a_dent@fennel.cc.uwa.oz.au writes: >In article <19464@netcom.UUCP>, lpendley@netcom.UUCP (Lou Pendley) writes: > >2) 4D >PROS >- some very sexy externals announced (haven't seen them yet) Yes, they include 4D Write and 4D Calc. 4D Write is a word processor that allows merging by directly selecting fields and files and inserting them into a letter. 4D Calc is a very nice spreadsheet that also ties right into 4D's database. A spreadsheet can be called immediatly from a 4D layout without leaving the layout. You can even define a spreadsheet on a field. When entering a formula in 4D Calc, popup lists of all the available files and fields are available to insert in the formula. Because 4D Calc and 4D Write are external code resources, these can be called just like any other 4D procedural command. >- I find the procedural language easy to use, given a Pascal background > >- the packaging of scripts behind buttons/fields etc. is good for reducing > size of code, and building responsive interfaces. > >- has a great user-defined search editor >CONS >- is ABSOLUTELY DISGUSTINGLY BUGGY - went from 2.0 to 2.0.11 before version 2.1 > which still has major bugs that can lose data (eg: a set of circumstances whic > fail to save changes the 2nd time into a record!) This statement doesn't apply because 2.1 is now released. Many problems have been fixed but I'd suggest staying away from subfiles. Subfiles is a poor approach. Like in any development system, there is usually a work around. In 4D, it is best to use linked files rather than subfiles. >- uses a single application file and single datafile which are both rather > fragile > >- data size grows rapidly I'll agree with ya there! >- the packaging of scripts etc. becomes a problem due to the lack of a global > search - it can be difficult to find code. The Cross Reference will be available soon. I have seen it, it is simply wonderful. I have not seen any other database language have anything like it. The CR is now online and you can easily find things without having to look at a printout. Of course you can print one out though. > >- complex screens become slow and VERY memory hungry The new 4D Compiler solves this problem! The Compiler speeds up the scripting language but doesn't have much effect on database performance. Overall, the compiler make a significant difference in screens and procedures. >- some of the best features (eg: user-modifiable lists, record sets) either > don't work or corrupt data in multi-user mode Multi user development is sensitive and takes experience to do if effectively. 4D in multi user is not as nice as others but works well if done correctly. Client/Server will be announced at SF Expo next week. > >- the user-level report-writer is a pathetic columnar effort. So who has a better USER report-writer? I think it's nice for those who are not programmers but need to generate a report. Advanced reports can be done by a developer in the procedure language. > >- it's not portable to anything!!! Yup, 4D should only be considered if you intend to stay on Mac. There are import/export utilities if data needs to be transferred however. >- enforces key disk copy protection (UNFORGIVEABLE!!!) Yeah, major sin! I not about to support that! >The bottom-line is: >FoxBASE for dBASE compatability, report-writer and writing cheap systems with no >fuss over runtimes. (and speed). Also useful as a sort of super-Filemaker > >Omnis for bigger systems, with more complex interfaces and transaction support > >4D possibly makes it in for VERY complex interfaces, otherwise the bin! > Unfortunately, your comparisons are based on 4D 2.0 and not 2.1. Also, you analysis does not include the tools available for 4D... Compiler, Externals, etc. I've been working with 4D, Omnis and Oracle (in UNIX). Bottom line is that 4D development can be completed faster (assuming enough experience) than the others and my 4D client's are more satisfied.