ODBC and FMP

[Mike J]

I have a question that I cannot answer because I don't have the background in IT. It is important for me to understand these questions when I address a committee at my job about a direction we should take (from a user's point of view).

We need to develop a solution in house for a particular process from the ground up. A foundation solution was built in FMP 8.5. It isn't perfect but we would like to build on it. (Professional Developer-FMP Partner Level)

I've been told by our IT members that we would have to scrap this solution and build something more robust in a ODBC or SQL type database? I want to disagree with this because of the initial solution in FMP set forth by our foundation solution does 80-90% of what is described in our programme brief. The users are working with a FMP partner developer in hopes we can develop this foundation program further.

I'm finding it difficult to convince anyone in our IS that FMP is more robust than previous versions and that it is an appropriate solution to move forward on.

I know you can have a back end SQL table if file size becomes a problem. Just looking for comparisons so I can understand the pros and cons.

Please help!!

Mike

(If this is an inappropriate forum folder for this topic, please move to a more appropriate subfolder)

[Genx]

SQL equals large enterprise solutions -- backend datafile only. ODBC is sometimes used as the connection from the front end (potentially access, vb, .net apps etc.). Great file type, and good in general, issue however is development time, your looking at 3-5 times longer than FM depending on the structure, plus the cost per hour is likely to be higher.

FM.. Yeh, it's good, I'd say all the way up to medium ( < 250 ) and small businesses ( < 50) -- their user restrictions are 100 IWP sessions, and as far as i remember 250 standard connections per server -- If those concurrent connection numbers are within your spec, thats fine, if you wanted to pay $2xx USD per client license (if you need the client that is) that's also fine.

In terms of filesize... FileMaker currently supports File Sizes of up to 8TB (8192GB or 8,388,608MB or 8,589,934,592KB) of information -- remember however that text data (which is what your database likely primarily consists of is measured in bytes I don't know of many medium business databases [of any file format] that go past 100GB), 2,500,000 Tables and supports internal SQL command execution -- meaning you don't have to use the GUI if you don't want.

It can act as an ODBC source, and can import via ODBC.

That's about all the random fact's i can think of at this stage :

[mr_vodka]

Here are my views on using FM verses other larger applications such as Oracle, SQL Server, MySQL, etc.

Each scenario deserves a different evaluation. Ulimately it is what makes sense for the client's needs. The benefits of FM are that is it usually a lot cheaper and faster to build applications with. However, if the system is large enough where there are thousands of users, then it may be better to evaluate other systems.

If your client usually wants quick turn arounds, ad hoc reports etc. Then FM may be a good choice, however, if they are a very large company where they can afford to take their time with enhancement deployments, then other apps can be used.

I find that most IT people out there are afraid of FM because they do not really know too much info about it, and as we all know people usually tend to stray from things that they are unsure about. So they would rather stick to something they are more familiar with such as SQL server, Oracle, etc.

[The Shadow]

You could just show your current FM solution to your IT guys, and tell them when they have something comparable written using other technologies that they approve of to let you know. ^)

[mr_vodka]

Hi Shawn,

LOL. You should see our software testing group. They have no idea how and what to test for in regards to our plugins that we use. I mean I know that its their job in testing to make sure that all company software is safe to use here, but watching them struggle is very entertaining actually. They cringe when they hear anything FM related. :)

[Genx]

LOL, Love It... FM really seems to have bad connotations relating to it, mainly because it's so easy to use, and with things that are easy to begin using, you can get people with absolutley no design experience producing software (unlike with sql where you actually have to know what your doing to begin a project). I think that's where the issue originates, FM itself is a sturdy peice of software but when used incorrectly... I guess IT admin have seen a few bad solutions and dump them all into the same FM basket.

[Mike J]

Many Thanks to all of your views. It's very helpful and enlightening.

Any ideas on how to stroke the ego of your favorite IT individual while convincing them that they are (sorry, might be) wrong?

Mike

Edited March 9, 2007 by Guest

[The Shadow]

Stroking: Well, versions of FM before 7 were kinda weak from an IT point of view (only a single table allowed per file), so you could point out that things are much better now. Actually, ScriptMaker is still kinda weak compared to what can be done with other languages. xDBC connectivy has improved a lot in recent years too (it used to be absolutely horrible, now its just weak ^)

More FM positives:

Also, its not like you're really "locked in", you can always export the data out to a full DBMS if FM stops meeting your needs. Since it sounds like you have most of a solution in place, I'm not sure what the hurry is to get away.

Of course, when you leave, you might lose support for things like Unicode and fully indexed (searchable) styled text in your text fields depending on what tech you decide to move to.

[Nemo]

And dont forget with the advantageous release forthcoming of FM9 they'll be able to use FM as a front end for sql (or was it mysql?) in either case 9 will be the end of IT naysayers - to a degree. With 7+'s account and security options, 8+'s object oriented programability, internet posting and odbc controls, an 9's SQL and event driven abilities, there's everything an IT person could want for a database. (I should know, I do IT for my company, and love the cost saving, quick deployment and stability of FM.)

[Genx]

... Rumoured, how sweet it would be though... but Rumoured nonetheless.