Results 1 to 10 of 10
  1. #1
    Join Date
    Nov 2005
    Posts
    4

    Unanswered: Access / SQL Server or Filemaker from Paradox?

    I've been programming in Paradox since DOS, but one mail-order database is getting rather large (100K client records, and associated orders, etc).

    Our client wants us to move to Filemaker. In fact he'd like to have a 3rd party write the programme and me maintain it. The current package has been written & maintained by myself, with an awful lot lot going on in the Object PAL code.

    I already have a copy (legal) of SQL Server & 10 licences for Access, and think that's a better option to re-develop in (although I could do with some training in both).

    What are the pros & cons for each app, and what would people recommend. I'm going to cross-post into Access, Paradox & Filemaker forums to get an equal view.

    Thanks

    Mark

  2. #2
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    If he wants an efficient, robust, scalable solution than develop the database in SQL Server. Use MS Access as front-end for the time being, but you will eventually want to migrate to other interfaces.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  3. #3
    Join Date
    Apr 2008
    Location
    Dallas, Texas
    Posts
    22

    MS SQL, FileMaker or Paradox

    It depends on what you want. Yes, MS SQL Server is probably better on the enterprise level if you don't mind longer development times (read $$$) and products that are hard to modify down the road. Both Paradox and FileMaker are more in the rapid application development model of databases. Paradox was great in the mid 90's, but Access/MS SQL took over when MS started bundling Access with MS Office, and Paradox has slowly withered away against that competition. However, FileMaker continues to grow with an active development community and a version released in 2010. FileMaker's target audience are small to medium sized companies that want a combined product that makes it easy to rapidly develop and change a database. It has slowly grown much more robust and even shares tables with MS SQL, Oracle and MySQL. Also it works on both Macs and Windows. For clients who need a product with low development dollars and a small to midsize company, it is a better product. MS SQL Server competes with the big boys if you need enterprise level databases, but with it come complexity and expense. The few enterprise level systems I work with have only a few users and huge sized databases and MySQL has worked well for them and the price is great. If you need more database tools, PostgreSQL is a good solution. More people migrating from Oracle or MS SQL to open source feel more comfortable with PostgreSQL than MySQL. If you have no care about money, Oracle and front ends like SAP are the way to go. MS SQL is a wanna-be Oracle... but not quite and MS SQL does cost less usually. Avoid Paradox since it is a shrinking community. Assuming you are cost conscience and a small to medium sized company, FileMaker will cost you less to develop and is very powerful. Also, FileMaker is much easier to secure and supports AD and OD. Don't fall into the trap of some MS Access developer who doesn't know Access is only supposed to be the front end access to a real database like MS SQL. Access is for the front end user interface and any other use is not supposed to be for production purposes (if you don't believe me, ask Microsoft!).

  4. #4
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    Aside from the actual product cost, I don't think it can be objectively stated that development on FileMaker as a database platform will be cheaper than development on SQL, or any other more or less "real" database platform. And what mostly caught my attention, was this unfounded statement:
    ...if you don't mind longer development times (read $$$) and products that are hard to modify down the road.
    How can it possibly be harder to modify the underlying database structure in SQL vs. anything else, including FileMaker or Paradox? I've worked with Paradox starting with its DOS version, prior to and including 4.6, then moving to Visual Paradox for Windows, and any structural modifications must be addressed in the front-end code, while making those modifications in the backend was even harder, than it is in either SQL or Horacle (my personal preference is SQL, thus the name ). And when talking about "unlimited budget", why would you want to put yourself though pain, suffering, and potentially through late termination of the project, by going with SAP on Oracle? 75% SAP implementation attempts end up in the trash can! The reason is simple - it requires an army of SAP consultants of different flavors, and 3 to 8 years of implementation (sometimes indefinitely), before a business can even see the first screen. None of SAP installations cost less than 10 mil in the first 3 years, and that's just for starters!
    So, before presenting "articles" for or against a specific database platform, I'd suggest at least work with a couple of them, and see where they lead. Let alone read some bios of this forum, they may tell you something.
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  5. #5
    Join Date
    Apr 2008
    Location
    Dallas, Texas
    Posts
    22

    Where FileMaker fits in

    Well, working gov't contracts, I can compare the difference. But forget that... lets look for the reason. The reason is what people need after development are usually modification to user interfaces and minor tweaks in the data structure. OK, so FileMaker isn't much easier than others to modify the structure, but User Interface is where FileMaker provides easier to use and more powerful features and that is why people buy it for rapid application development. Study after Study has shown that FileMaker development costs less than traditional SQL development and the primary reason is the tools for the user interface are more complicated and less flexible. It can be argued that these tools (usually various programming languages or PHP, etc) are more powerful. But it takes so much more work to get the same result, it costs a lot more in development. Unlike larger companies that can defer large enterprise costs among a lot more people, small to mid size companies need a database tool that gives them the power they need via these tools without the complication. I do database work along side Oracle and Notes/Domino guys all day long. Great for enterprise work... sucks for anything less.

  6. #6
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    I'm working gov't contracts as well, and I do see what's going on. I have a slew of platforms to compare in terms of efficiency of development or ease of post-development modifications. It's not the tools that are being used, it's the resources that are allocated to use them. And when it comes to gov't - it's not the quality of the resources, but rather the relationship between contracting company and the higher-ups in a specific dept or division. So, if the study is made based on this type of environment, - its results are very-very subjective. Besides, I also live in the real world, where (again) tools don't make a diference, unless we're talking about putting an enterprise solution on text files and hiring a Notepad DBA to maintain it.

    In short, I just don't see substance in your argument, sorry.
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  7. #7
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Quote Originally Posted by taylorsharpe View Post
    Study after Study has shown that FileMaker development costs less than traditional SQL development and the primary reason is the tools for the user interface are more complicated and less flexible.
    You are confusing the interface with the database engine, and those are two separate entities, though in non-enterprise software packages such as FileMaker and MS Access they are closely bound.

    Since you can develop interfaces for Microsoft SQL Server (or even Oracle) using many different technologies, but with FileMaker are limited to its proprietary technology, your statement that application development in FileMaker is less complicated is dubious, and your statement that it is more flexible is demonstrably incorrect.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  8. #8
    Join Date
    Apr 2008
    Location
    Dallas, Texas
    Posts
    22
    Yes, and people like you come along all the time to compete for the jobs us scientists need and we simply have you quote the Oracle or even Domino price (goodness I hate that product), then have the FileMaker guys quote theres and FileMaker has always underbid. Part of the issue is that as scientists, we need many large database and probably not a whole lot of users... rarely more than 100 at a time. So FileMaker fits well in that size and has easy to use user interface development tools that scientists that are non-computer professionals can get comfortable using. The Oracle databases we use always have to have a contractor to modify the user interfaces and lots of improvements are never done because we don't want to spend the money. In its sweet spot of small to mid-sized company needs for rapid application development, FileMaker can be a great choice of software. In many ways it doesn't really compete in the same area of databases as the big iron SQLs, but I get a laugh at guys like you that try to compete the big iron SQL stuff for the types of databases my division needs. We need lots of smaller databases with flexible user interface and easy security. And I agree FileMaker does not compete in the large enterprise database level where there are thousands of users and the interfaces are very static and only need developed once. But I think you comments show are lack of understanding what a rapid application development program is and when it is a better choice.


    Quote Originally Posted by rdjabarov View Post
    ....In short, I just don't see substance in your argument, sorry.

  9. #9
    Join Date
    Apr 2008
    Location
    Dallas, Texas
    Posts
    22

    FileMaker

    You are correct and I should have read your post before my previous post. Yes, the SQL databases are just the back ends and you can use many different front ends whereas products like FileMaker are primarily a single customer proprietary interface. And this is the wrong forum for talking interface since it is the server forum. My bad.



    Quote Originally Posted by blindman View Post
    You are confusing the interface with the database engine, and those are two separate entities, though in non-enterprise software packages such as FileMaker and MS Access they are closely bound.

    Since you can develop interfaces for Microsoft SQL Server (or even Oracle) using many different technologies, but with FileMaker are limited to its proprietary technology, your statement that application development in FileMaker is less complicated is dubious, and your statement that it is more flexible is demonstrably incorrect.

  10. #10
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Granted, if you are developing a lot of short-lived databases, AND they are shared by a very limited number of users, AND you are not storing huge amounts of data, AND you do not need to perform complex set-based calculations, you can get-away with non-enterprise solutions such as FileMaker or MS Access, which are perfectly adequate for allowing three to five users to view and edit records.

    But if you took the time to learn SQL Server using a free or low-cost solution such as SQL express, you would find the data manipulation tools MUCH more powerful and efficient than you would get from a PC-based application.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •