I know NOTHING about Oracle™ . . .

[KarlGauss]

. . . except that Larry Ellison is a very wealthy guy. So, I figure I should know at least something about his showcase product.

Now, I do know that Oracle is a "relational data base". But, that's about it. What I'd like to know is who tends to use it? Is Oracle something that can serve both the "home user" as well as business? And, with respect to business use, what kind of companies are we talking about? Banks? Manufacturers? Department Stores? Is Oracle the "brains" underlying amazingly linked sites such as Amazon and eBay? Finally, how much does it cost? I assume a fair bit, otherwise Larry wouldn't be worth $28 billion (http://www.forbes.com/forbes/2010/0329/billionaires-2010-wealth-richest-people-slim-helu-gates-buffett-top-20.html).

Thanks!

[Bijou Drains]

Mostly used by big businesses for all sorts of things involving storing data. You can use it as a regular database and write your own applications or Oracle will sell your their apps to go with the DB. For example they have Oracle Financial which is for accounting. Oracle Clinical is for clinical trial data.

It's not cheap, it runs on big mainframes and also on Unix workstations. It's used across many types of industries. People who run the systems are Oracle DBAs and they can make a lot of money.

[Knorf]

I used to be an Oracla DBA. Glad to leave that profession behind! (The money was good but not insanely so, partly because I was working for a non-profit.)

Oracle is a widely used database, no question, and it's expensive and requires well-trained people to take care of it. In my case we wrote our own apps for it, but even so you really do need someone trained to be your DBA to keep it running properly and efficiently. Although frankly I did spend more time maintaining and tweaking our own apps.

The users for Oracle tend to be people or corporations who need to take their data very seriously: banks, insurance, large corporations, and the like. I'd say Oracle is overkill for your average home user. I'm not sure what Amazon and eBay are using, but certainly they're the scale of the typical kinds of companies that are using it. I suppose small businesses might reasonably be able to justify it as well. The basic idea is for the database to be extremely secure, stable, and reliable. Clearly this is important if you wish to avoid a lot of pissed-customers demanding to know what happened to their accounts, or something like that.

As for what it costs, I don't remember, but certainly the cost scaled with the desired features and number of site licenses. It wasn't cheap. There is a standard version and an "enterprise" edition (or used to be), but lots of options. Also a non-trivial cost is paying for the training--anyone who directly interfaces the database really needs to have had some decent formal training, otherwise you can really, really screw it all up. In my case, I was sent to Oracle for official courses.

(Incidentally, it doesn't need Unix or a mainframe by any means. We ran it on a desktop PC with Linux. It runs fine in Windows and even on laptops.)

A quick check: standard edition is $350 per user, minimum 5 users.

[HMS Irruncible]

A relational database is like a monster-truck spreadsheet system where all the spreadsheets can be linked to each other, you can have billions of rows of data, and you can write highly targeted queries with a specific kind of language called SQL. Usually people don't sit there poking around directly in the database using SQL, although you certainly can. Normally some other software or web application will talk to it using a predefined set of SQL statements.

It's actually a jillion times more complicated than that, but that's enough to get you started.

[Superfluous Parentheses]

Just to comment on the "home user" part of the OP, the idea that a home user is even capable of installing oracle and start it up (let alone configure it and keep it running) is... let's just say it's not a good idea even to try. Last time I checked there were free trial downloads for the database so if you really want to, give it a shot. At best, you'll be wasting several Gb of disk space with nothing useful (to anyone) to show for it.

The other responders aren't kidding when they say Oracle requires specialists. If you want to try something vaguely comparable that might be useful to the home user, install MS Access (which has pretty and useful frontends and is priced at home user prices), or MySQL or Postgres if you're willing to dig a little deeper for free.

[Knorf]

Og, you're telling the truth. I'm not sure if it's gotten easier, but in my day even installing Oracle and creating a test database was non-trivial, at least in Linux. Hopefully it's gotten easier.

[KarlGauss]

Thank you, all. Very helpful!

(And, I definitely wasn't looking for a 'home user' version of Oracle or even something similar. Just curious was all.)

[DMC]

If you want to just learn the language that most of the big RDBMS' use, then it's actually not all that difficult. While each vendor has his own version of SQL, it's fairly simple to learn the basics. It can take years to master fully, but you can be up to speed in basic query writing quite quickly.

As for administration, it varies so much by each vendor that you really would have to specialize.

If you want to play around, I'd recommend either SQL Server Express (free) or SQL Server Development version ($49 or so). The first is sort of a personal edition, while the latter is a full blown high end piece of software that would cost you about $25,000 per processor, if you were using it for production work. Once you learn SQL, you can fairly smoothly transition as a developer from one vendor to another, but not as a DBA.

[Zakalwe]

It's not cheap, it runs on big mainframes and also on Unix workstations. While the rest of your post is substanitally correct, this it not. Oracle does not run on mainframes. It runs on Linux, Unix, and Windows servers.

[t-bonham@scc.net]

While the rest of your post is substanitally correct, this it not. Oracle does not run on mainframes. It runs on Linux, Unix, and Windows servers.On big mainframes, they use IBM's DB2 database. It's also a relational data base (the original one) and also uses SQL language to obtain the data.

[xash]

The SDMB uses MySQL (http://www.mysql.com/), which is now owned by Oracle Corp.

ETA:

They got MySQL via this deal:

Sun Microsystems
Website: sun.com
Location: Santa Clara, California, United States
Founded: February, 1982
Acquired: April 20, 2009 by Oracle Corporation for $7.4B in Cash

[Bijou Drains]

Oracle used to run on mainframes but I guess they quit making that version. Wikipedia says it runs on mainframes but they note that was as of 2006 and they also mention that they dropped a lot of platforms.

[HMS Irruncible]

On big mainframes, they use IBM's DB2 database. It's also a relational data base (the original one) and also uses SQL language to obtain the data.
There are a number of different DBMS systems that run on mainframes besides DB2. DB2 is not the "original" relational database. 30 seconds of googling would tell you this.

[tetranz]

There is a free Express edition (http://www.oracle.com/technology/products/database/xe/index.html). They seem to be following Microsoft's naming convention who have a free Express edition of SQL Server.

I used to use what I think was the predecessor of this called the Personal edition. I ran it on Windows 95 and then later Windows NT. I used as a test system for developing applications to run on a "real" Oracle system.

The Express editions of either Oracle or SQL Server are quite usable for a small web site or something although it's hard to see why you'd use it instead of Postgress or MySQL.

[Nava]

I usually tell my customers that SAP and Oracle are "like the biggest Excel spreadsheet ever, only BIGGER." Those who are familiar with Access are told it's "like an Access database, with forms and tables and reports and so forth, only a lot bigger than anything Access can handle, and the forms and so forth are premade."

I don't really understand the technical details of it, but a lot of my SAP clients use a SAP ERP to manage a database that's actually Oracle's (you can also use an Oracle ERP to manage the database, and a SAP database, and... whatever, like I said it's not my corner of the room). The database is a huge file with every piece of data the company needs, the "ERP" is the program that lets users fill more data in and see the data in ways that make sense for the user. It's similar to how our browser let us interact with that SQL database holding every SDMB post: SAP is the "browser".

[AHunter3]

Oracle is the back end you use for FileMaker when you have more than a few terabytes of data or need to accomodate more than 1000 concurrent end users.

[RaftPeople]

Oracle is the back end you use for FileMaker when you have more than a few terabytes of data or need to accomodate more than 1000 concurrent end users.

Or if you want very good concurrency at any application size. Oracle excels in this area. (I'm not sure what to make of your FileMaker comment, do you think FileMaker offers everything Oracle does up until the limits you listed?)

[aceplace57]

I never liked relational databases. Unfortunately, my employer purchased Banner application software and it uses Oracle. So, I've gotten a gut full of Oracle. My biggest headache is their constant updates. We started with Oracle 4 and have migrated to every version since. I think we're on Oracle 9 now. Every change in Oracle means that we have to update & test the Banner software. A major pain in the arse.

Oracle originally used the client/server model. That changed a few years ago. I think it was Oracle 7. Everything is hosted on the web. Even SQL requires a web client. That was a huge conversion for us. We had to update and train nearly 400 users. :eek:

[blondebear]

I dated a couple of women from Oracle's Sand Hill campus back in the 80's. Cindy and LaVonne, where are you now?

[aceplace57]

Since you asked about Oracle.

Oracle Database Instant Client is what we now use on workstations to connect to Oracle. It's more difficult to set up than the old client/server connection. Instant Client does give you an ODBC connection and it has a SQL *Plus client. Our users like Crystal Reports.

[susan_foster]

My company did a POC a few months ago for a bunch of database vendors, including Oracle. Interestingly enough, just about every one of the vendors we brought in was going down the appliance path - selling a combination hardware/software. This included Oracle - they have something very, very new - we would have been one of the first to use it.

[FalconFinder]

All I can say about Oracle, is that I hated using it. More than likely, though, it was the company's fault for how it was put together. I forget the names of the programs used before switching to it, but they were much easier to use.

The Oracle screens were so busy and it was just so freaking cumbersome to use as the end user.

This was for a Technical Support database, along with Sales and customer service, so it could also just be how we were using it.

[friedo]

Oracle originally used the client/server model. That changed a few years ago. I think it was Oracle 7. Everything is hosted on the web. Even SQL requires a web client. That was a huge conversion for us. We had to update and train nearly 400 users. :eek:

That is not true at all, and frankly makes no sense. I think you got some shitty training.

[AHunter3]

(I'm not sure what to make of your FileMaker comment, do you think FileMaker offers everything Oracle does up until the limits you listed?)

It does not, and vice versa.

FileMaker is a RAD environment. You can change field names, table names, how tables are related, the behavior of scripts, and the appearance of the user interface while a couple hundred users continue to use the system.

In Oracle (or for that matter MS SQL Server or MySQL or PostGreSQL etc etc) what you've got is a very fast engine that scales up almost effortlessly, with no interface to speak of; so any deployment of it is going to have a front end which exists as a separately coded environment whether it be in Brio or Crystal Reports or in php files or in some other front end environment whether open source or proprietary. These may or may not exist only in a centralized location (they may instead be distributed as "reporting applications" to various nodes in the network) and they may or may not communicate with each other (in the simple sense of one php page posting data to the next php page or in more complicated cascades of interdependencies). ALL OF THAT has to be considered before any changes can be made, and the changes synchronized, which is usually a sufficiently messy task as to require testing (sometimes extensive testing with an actual plan of what categories of sample data to throw at it). That makes changes time-consuming and expensive, and that in turn means you need to study in advance exactly how you need it to behave and then you implement that, after which point you mostly have to live with what you opted for.

Working in modeling clay versus carving in basalt.

Different strengths, different weaknesses. You shouldn't try to run the Social Security Administration of the United States on FileMaker, and you shouldn't try to run your mid-sized company in Oracle.

[RaftPeople]

It does not, and vice versa.

FileMaker is a RAD environment. You can change field names, table names, how tables are related, the behavior of scripts, and the appearance of the user interface while a couple hundred users continue to use the system.

I can see value to that in a prototyping environment, but that doesn't make sense in a production environment.


In Oracle (or for that matter MS SQL Server or MySQL or PostGreSQL etc etc) what you've got is a very fast engine that scales up almost effortlessly, with no interface to speak of; so any deployment of it is going to have a front end which exists as a separately coded environment whether it be in Brio or Crystal Reports or in php files or in some other front end environment whether open source or proprietary. These may or may not exist only in a centralized location (they may instead be distributed as "reporting applications" to various nodes in the network) and they may or may not communicate with each other (in the simple sense of one php page posting data to the next php page or in more complicated cascades of interdependencies). ALL OF THAT has to be considered before any changes can be made, and the changes synchronized, which is usually a sufficiently messy task as to require testing (sometimes extensive testing with an actual plan of what categories of sample data to throw at it). That makes changes time-consuming and expensive, and that in turn means you need to study in advance exactly how you need it to behave and then you implement that, after which point you mostly have to live with what you opted for.

It sounds like you are talking about a reporting only environment as opposed to an OLTP environment.

Working in modeling clay versus carving in basalt.

Different strengths, different weaknesses. You shouldn't try to run the Social Security Administration of the United States on FileMaker, and you shouldn't try to run your mid-sized company in Oracle.

Assuming we define a mid-sized company as 50m to 500m in sales (ERP vendors usually put mid-size in this general range), I would say Oracle is an excellent choice (I would choose it over others purely for the way it handles concurrency). At the low end (<50m) the advantages start to disappear.

Are there any OLTP FileMaker systems of decent size in use? I'm not aware of any. How does it handle concurrency?

[AHunter3]

Standard record locking. You can script the locking of a record, but it also happens automatically when someone clicks into a record and starts editing it.

I'm a professional FileMaker developer (12 years at it) and most of the time when I work I'm working in a production environment. It makes all kinds of sense when the powers that be are still fleshing out how the db should behave and most of the end users get some input into desired db features & behavior. ETA: And no they aren't "reporting only". We don't use the acronym OTLP. It would be like saying "cars that GO somewhere". They all do.

[RaftPeople]

Standard record locking.

Locking varies quite a bit in different dbms's. One of Oracle's strengths is that readers don't block writers by default and you get a view of the db at an instant in time.


You can script the locking of a record, but it also happens automatically when someone clicks into a record and starts editing it.

Meaning the type of lock that prevents others from reading? or the type that prevents others from updating?

Either way, what happens when the person editing the record decides to go to lunch before finishing and someone else is running a process that needs to update that record?

[HMS Irruncible]

Oracle originally used the client/server model. That changed a few years ago. I think it was Oracle 7. Everything is hosted on the web. Even SQL requires a web client. That was a huge conversion for us. We had to update and train nearly 400 users. :eek:
Breathtakingly wrong. Even with Oracle 10 you can use a generic SQL client like Toad using the SQLNET protocol. No web required. What is it about this subject that makes clueless people crawl out of the woodwork to put in their wrong two cents?

[aceplace57]

I was simply stating what happened at my job. We ran Banner with Oracle with client/server for 6 years. We had 4 production servers and 2 test. Workstations had a network drive mapped to one of the servers. We ran Banner from that drive. Our campus has over 500 staff and faculty workstations using Banner.

After a major Banner/Oracle upgrade all the servers were taken down. We had to modify every workstation so it didn't create a network drive anymore. Banner is now started using a web browser (usually IE). For reporting, Oracle Database Instant Client has to be installed on the workstation. Instant Client includes SQL *Plus. I use it almost every day for queries. We've used this setup for almost five years.

For us, Banner and Oracle are tied at the hip. An upgrade to Oracle usually means a new version of Banner. That's just how it works.

[HMS Irruncible]

Okay, first, "network drive" has nothing to do with Oracle, that's a Microsoft piece of work there. And internet explorer has no relationship to Oracle. Oracle requires no web browser for anything. What you've got there is this Banner , which is clearly a piss-poor piece of software written by idiots with some bizarre configuration requirements, and nobody smart enough to understand the difference between a relational database and a jacked-up software package. Just because you access them both by clicking the same mouse and staring at the same monitor doesn't mean they're the same things.

[Zakalwe]

Standard record locking. You can script the locking of a record, but it also happens automatically when someone clicks into a record and starts editing it.

I'm a professional FileMaker developer (12 years at it) and most of the time when I work I'm working in a production environment. It makes all kinds of sense when the powers that be are still fleshing out how the db should behave and most of the end users get some input into desired db features & behavior. ETA: And no they aren't "reporting only". We don't use the acronym OTLP. It would be like saying "cars that GO somewhere". They all do.Sorry, dude. In a "professional" environment, you are *never* making changes directly in production. That's what DEV, TST, and STG are for. I'm assuming you work for very small clients (ie, less than 10 concurrent users). It's probably a great living for you and you're absolutely right that you don't need Oracle for that market. Make it mission critical with millions of records and thousands of users and it's a different world. Oracle or SQL Server (in a robust cluster) isn't an option at that point, it's which one.

[AHunter3]

One of Oracle's strengths is that readers don't block writers by default and you get a view of the db at an instant in time....
Meaning the type of lock that prevents others from reading? or the type that prevents others from updating?

When I refer to record locking I mean preventing editing / updating. Anyone can view any data that their privilege set allows them access to regardless of record locking.

Either way, what happens when the person editing the record decides to go to lunch before finishing and someone else is running a process that needs to update that record?

Usually they complain to me (FmPro sysadmin) and once I verify that they aren't at their workstation I nuke them from orbit have FmServer disconnect them which unlocks the record in question.

'm assuming you work for very small clients (ie, less than 10 concurrent users).

You assume wrong. Average load 120 concurrent users, peak load around 450 concurrent users. Cross-platform, over wide area network.

[Zakalwe]

You assume wrong. Average load 120 concurrent users, peak load around 450 concurrent users. Cross-platform, over wide area network.And you make changes directly in PROD, during the work day? All I can tell you is, not on my watch. What's your rollback plan, if the change goes bad?

[AHunter3]

And you make changes directly in PROD, during the work day? All I can tell you is, not on my watch. What's your rollback plan, if the change goes bad?

Unmake it.

Why do you ask?

Actually I know quite well why you ask. In YOUR environment, making the change (or backing out of it) is most often a huge affair. In mine, it's not much more complicated than editing the contents of the post I'm writing this very moment.

OK in all fairness, for really MASSIVE structural changes (like splitting Table X into tables X1 and X2, deleting some of the fields from X1 and a good many of the others from X2 and establishing a new one-to-many rel between X1 and X2, and making Table Y, formerly a direct child of X1, into a child of X2, and redoing all the layouts, scripts, value lists and etc, and commuting the data with appropriate modifications and default values) is NOT something I'd do in the live system. I'd do that on a local copy and then shut down the main system, dump sample data from the dev copy on the dev HD, import, and run parsing / splitting scripts to convert, then stick the new version on server. Much as you probably would.

But for simple stuff like adding a new table, adding or changing a relationship, adding 15 new fields, adding 5 new screens, adding a couple of reports and changing validation formulas for acceptable values on 5 existing fields, that's day to day stuff and it HAS to be done with ZERO downtime and has to be ready before end of day.

The fact that Oracle folks would say "hell NO" to such a request is the very reason Oracle is not the right tool for the kind of environment where everything is still in such flux. Which does describe the vast majority of small to medium sized offices.

[Bijou Drains]

I did not know FileMaker was still around , I have not heard anyone mention it for 10 or so years. Does anyone use it outside the Mac world? Everything I hear now is Oracle, SQL Server or MySQL.

[Zakalwe]

The fact that Oracle folks would say "hell NO" to such a request is the very reason Oracle is not the right tool for the kind of environment where everything is still in such flux. Which does describe the vast majority of small to medium sized offices.Got news for you. It's not Oracle that makes says "hell no". Oracle supports those kind of changes just fine - even in PROD. It's the IT folks, the Audit folks, the Security folks, the Accountant folks, and the Management folks that say no.

Now. If you're making the kinds of changes you're talking about in PROD then you're working in a RAD/SCRUM world and that kind of stuff is acceptable there. You (or more properly your clients) have traded the hassle of actually properly designing the system before deployment for the risk of you making those kinds of changes on the fly. It's a valid decision as long as it's made from an educated position.

Don't mistake the practices of DBAs for Oracle's abilities. I defy you to find anything that Filemaker can do that Oracle can't. That's different than saying that because you do things in your Filemaker database that a trained Oracle DBA would resist that Oracle is *incapable* of doing it.

[Zakalwe]

Damn. Edit window closed:

What do you mean "unmake it"? You're talking about changing relationships in production. What happens when someone has edited a few hundred of those records and you try to "unmake" it? They just lose the work?

[AHunter3]

Of course not. I can change relationships without modifying the tables to which the relationships apply. If It seems reasonable and appropriate, I can modify, move, or reconfigure the data that they've entered so as to most appropriately correspond to the original / 'unmade' schema after changing the relationship, but I don't have to. If I do, that's another script, perhaps 45 minutes' to an hour's work on top of the relationship mod itself.

No big deal.

[AHunter3]

Now. If you're making the kinds of changes you're talking about in PROD then you're working in a RAD/SCRUM world and that kind of stuff is acceptable there. You (or more properly your clients) have traded the hassle of actually properly designing the system before deployment for the risk of you making those kinds of changes on the fly. It's a valid decision as long as it's made from an educated position.

I agree with every word of that.

Don't mistake the practices of DBAs for Oracle's abilities. I defy you to find anything that Filemaker can do that Oracle can't. That's different than saying that because you do things in your Filemaker database that a trained Oracle DBA would resist that Oracle is *incapable* of doing it.

Agreed there also, but it's generally going to TAKE YOU LONGER. Because you have to mimic those changes in your front end which is generally a separate environment with a different code set. It's HARDER for you to do it. Oracle itself though? Yeah, no question about it, it'll totally do it the moment you ask it to. Drop yonder table, change what that column's data type is, whatever.

Oracle is seriously powerful and deserves its reputation.

But for a lot of deployments using Oracle is like using a flamethrower when a Bic lighter would have been the more appropriate (and more easily handled) tool.

[RaftPeople]

Actually I know quite well why you ask. In YOUR environment, making the change (or backing out of it) is most often a huge affair. In mine, it's not much more complicated than editing the contents of the post I'm writing this very moment.

That really isn't a limitation of the database engine, it's really more of a change management process that exists to protect the business from the risk of the application falling apart.

Here's a real typical example I was working on today: we are going to start tracking the serial number of certain items as they are packed for shipping in the distribution center, which are then transmitted to a separate system where they undergo additional processing. In your environment, wouldn't you want to test it, train the users, etc.?

The bulk of the work in apps is not installing the changes, it's carefully designing a good process/system that meets the business needs, building it, validating it really works, training users and managing the implementation, lather, rinse repeat.

[RaftPeople]

Agreed there also, but it's generally going to TAKE YOU LONGER. Because you have to mimic those changes in your front end which is generally a separate environment with a different code set....

What is it that you think is being mimiced? The storage of data is different from the presentation and ability to change that data. If you add a serial number to a transaction, whether you have FileMaker or Oracle, somehow you need to modify the screens that accept input for that transaction and add the serial number, right?

[AHunter3]

Nope. Or at least not always or even by default.

In FileMaker you can add a serial number that auto-increments for each new record without having to modify a single screen.

You can change the name of every single field in the table without having to modify a single screen.

Or script.

Even external files of completely separate solutions that just happen to reference a table in this one need not be touched in order to "just know" about such a change.

You can change how a relationship works without changing anything in the GUI or within the scripts. (now if you change a nominal relationship so that it now aims at a totally different TABLE, that's a different story).

[RaftPeople]

Nope. Or at least not always or even by default.

In FileMaker you can add a serial number that auto-increments for each new record without having to modify a single screen.

Well, in the example I was giving, the serial number is barcoded on the product, it needs to be scanned into the system (the idea being that there is some additional piece of data that needs to be captured for this transaction that is also used by a different application/database downstream).

Working from this example, how would you add something like this into your system using FileMaker, specifically how is it easier than in other environments?

[Zakalwe]

Even external files of completely separate solutions that just happen to reference a table in this one need not be touched in order to "just know" about such a change.Okay, now I've got it. It's like Access with an integrated GUI/reporting engine. I still don't see how the above works though. If you change the name of the CLIENT table to CUSTOMER, I understand that FMPro can update it's internal references (Access will do the same thing), but how can FMPro reach out to the external service and update it? Does it just maintain an internal translation table where CLIENT=CUSTOMER?

[AHunter3]

Low level table IDs don't change, and the external system (assuming it is ALSO written in FileMaker) uses those and doesn't care what name you give to a table. As long as it's really the same table, it still still be pointed at it.

Same for field names. If your archiving company changes from "Arcus" to "Iron Mountain" you can change the field ArcusID to IronMtnID and click "Done" and move on to the next task.

[RaftPeople]

Well, in the example I was giving, the serial number is barcoded on the product, it needs to be scanned into the system (the idea being that there is some additional piece of data that needs to be captured for this transaction that is also used by a different application/database downstream).

Working from this example, how would you add something like this into your system using FileMaker, specifically how is it easier than in other environments?

Still curious about your response to this AHunter3.

You stated that environments that use Oracle, etc. have to mimic or duplicate work, but your example was between specifying storage of data and specifying where data appears in the application, which are 2 separate issues.

If you need to add a serial number to the database and to various application screens, how can FileMaker eliminate one of those steps, it doesn't know which screen you want the new field to be used as input and which screens it should appear as output, so I don't understand what needs to be mimiced.

[AHunter3]

No, you're quite right about THAT. If I am adding a field that has to receive user input, I bloody well have to add it to the relevant layouts (GUI screens that end users see and use) so they can input into them.

OK technically speaking FileMaker DOES by default automatically add new fields to the layout you currently have open if & when the table to which you are adding those fields is the table whose records are being displayed by that layout. But I'm not going to tout that as a FileMaker advantage, as I find it a very annoying feature, one that I immediately disable in preferences. I don't want the damn field added to the layout by default. It won't add it to the right place on the layout and more often than not the fields I create are not intended for the GUI anyhow.



But if the existing relationship between Table A and Table B is currently Serial Number in Table A = Foreign Key in Table B, I can change the rel to include the provision that (constant field) One in Table A also equals IsActive in Table B (thus all the inactive Table B recs cease to be tied to Table A via that particular relationship); and once I've done so I don't need to search through dozens of scripts and modify each of them. In Oracle, reports would exist as saved queries in a reporting environment and I would have to search ALL of them for places where I had done a SELECT for fields in Table A and Table B where Serial_Number in TableA = Foreign_Key in TableB, and edit each of them so as to include the provision that TableB.IsCurrent = 1.

In FileMaker, the reporting environment and the data storage and searching environment is a unified system. But the GUI can't magically intuit what you want to do with new fields and etc so there's still work to be done in Layout Mode if you are making changes that involve adding new fields for end users to see and/or type data into, and I did not mean to imply otherwise.

[RaftPeople]

But if the existing relationship between Table A and Table B is currently Serial Number in Table A = Foreign Key in Table B, I can change the rel to include the provision that (constant field) One in Table A also equals IsActive in Table B (thus all the inactive Table B recs cease to be tied to Table A via that particular relationship); and once I've done so I don't need to search through dozens of scripts and modify each of them. In Oracle, reports would exist as saved queries in a reporting environment and I would have to search ALL of them for places where I had done a SELECT for fields in Table A and Table B where Serial_Number in TableA = Foreign_Key in TableB, and edit each of them so as to include the provision that TableB.IsCurrent = 1.

I'm not following what you are getting at here. In the serial number example, it was just an additional data element added to table A in this system (and in another system as well as some intermediate interface tables). Of all the places where data is selected from table A, I would go to a small subset of them and add the new field into the select and into the UI.

Not sure what the IsCurrent=1 is getting at (sounds like you are saying some rows are active and some aren't, but wouldn't that condition exist prior to adding additional data elements?). I understand you are specifying a conditional relationship, but I don't see how that is reducing work from an Oracle env. Is it because you specify that rule within your schema instead of within an application framework?

[AHunter3]

Yes, it's because I specify that rule within the schema (in one place) rather than within a reporting (external application) framework where it may require editing in many places.

[Mama Zappa]

There actually *is* a home version of it - which is, interestingly, free. I have it on my work laptop, as a way of practicing, trying out SQL, etc. I could develop a PC-based app using it as a back-end. I haven't investigated the legalities of marketing such a tool (of course for that to be an issue, I'd have to have a marketable concept!). There are certainly some restrictions.

The commercial version is very, very widely used (my last 3-4 clients have all been Oracle-based for example).

[AHunter3]

Yeah, I wish they'd make the freebie version available for MacOS X. I can install MySQL and PostGres but if I want Oracle I either have to pay for it or stick it on a PC instead.