Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

FMP to A5 - concerns...

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    FMP to A5 - concerns...

    Hello everyone. I'm new here and new to Alpha Five. I've been programming FileMaker since late 80's and have two companies that base products on it but enough is enough. I've got to have real power and extensibility. Anyway, we run a large complex medical app in FMP6 of which I'm now having to port to FMP8x due to the lovely FileMaker policy of not supporting past versions (read "not supporting developers"). I would have had to do it anyway because customers regularly run into the 2gig limit and "supposedly" FMP 7+ will go to terabytes. OK, a big plus..... if it really works (too much experience with FMP to trust them yet).

    Now, A5 is dbase based and I read it has the 2 gig limit. Is there more to it than this? Is the FMP file structure bloated compared to dbase? Do I need to re-design my tables, relationships, etc to squeeze out space? Are there any other similar issues regarding FMP - A5 that I would need be aware of before making such a huge move for my companies; this will be a big investment in time and effort.

    I have lots of other questions for the forum regarding A5 but will leave it at that for now. I know this is pretty general but I do appreciate any information/opinions/advise you may have. There seems to be plenty of written documentation out there but a forum with real users is where the real info lives... thanks again.

    #2
    Re: FMP to A5 - concerns...

    William, I would suggest you go through the excellent videos that showcase the power and functionality of Alpah5. Once you get enticed by these you could consider getting Dr. Peter Wayne's book on XBASIC and be introduced to some great applications (code included).

    I had come from a DOS based database and decided to successfully tackle the most complex component in that environment. My ability to do this was greatly facilitated by this forum which is one of the best resources I have ever come across and the only downside is that it can be addictive :D since I don't want to miss any threads because there are always some real world problems getting addressed and resolved. Getting exposure to these can help you get out of your current world view and enrich the whole database experience.

    Ken

    Comment


      #3
      Re: FMP to A5 - concerns...

      Thanks, Ken. My roots are in C and FoxPro with a little OOP thrown in. I originally moved to FMP because I was tired of low level programming. But I keep bumping into foundational deficiencies with FMP; I guess I'll have to get my hands dirty again with real programming. I'm just trying to get a feel for what I may be giving up in order to get something else and for me, is it worth it. I'll go through the videos, thanks.

      Comment


        #4
        Re: FMP to A5 - concerns...

        Alpha Five does have a 2g limit with the native .dbf table, but you can use it
        as a front end to SQL tables/servers and thus overcome that limit.

        Comment


          #5
          Re: FMP to A5 - concerns...

          I believe (correct me if I'm wrong) that a single Filemaker file contains multiple tables. In Alpha Five, each table is a separate file.Practically speaking, it's rare for a .dbf table to even come close to the 2 Gig limit. I know it can happen, but it's not common.

          As Melvin mentioned, you can use Alpha Five as a front-end to a SQL database, but until version 9 comes out, you won't be able to use regular Alpha Five forms, only Xdialogs. That may be more programming than you want to tackle at this stage of your learning curve.

          - Peter Wayne

          Comment


            #6
            Re: FMP to A5 - concerns...

            Thanks Melvin, so I would have to install something like MySQL and hook into that for data storage, right? Is this something that A5 developers do routinely and is it difficult? Sorry for the questions, just trying to get a grasp of things. I appreciate the comments.

            Comment


              #7
              Re: FMP to A5 - concerns...

              OK. The FileMaker 6 file that the original version was built on did not support multiple tables and as in FMP fashion had inteface, scripts, etc. bound to the file so I know there is bloat there. I had 50-60 different medical test forms running off of it and consequently it had >1000 fields but again, FMP 6 required that a lot of those fields were "support" fields, i.e., globals, calcs, etc. I think from looking at A5 structure that I can/should 1) get rid of a lot of the "support" overhead and 2) breakup the test forms into their own tables. This should significantly reduce the file size requirements.

              Is there strong cross-table query capability in A5? This was a problem in FMP. Thanks, all.

              Comment


                #8
                Re: FMP to A5 - concerns...

                Originally posted by fmpros View Post
                Thanks Melvin, so I would have to install something like MySQL and hook into that for data storage, right? Is this something that A5 developers do routinely and is it difficult? Sorry for the questions, just trying to get a grasp of things. I appreciate the comments.
                As for doing things routinely, that is hard to say. There are many A5 developers,
                but I have no personal knowledge of all the instances where it used used as a front end to SQL db's . Also, As Dr, Wayne pointed out, you cannot use A5 forms with the SQL. You would have to use ado or A5ado to interface(DML) and
                Xdialog to define your forms, so there would be a learning curve and lots of coding.

                Comment


                  #9
                  Re: FMP to A5 - concerns...

                  Hello William,

                  There were some reasons I left Filemaker 5.5/6.0.

                  1. The very limited scripting language of FM.
                  2. FM proved to be very limited for the task I want to use it.
                  3. In the end I was sick and tired of the so called graphical way of building databases. FileMaker looks like PowerPoint with a database engine.
                  4. The tiresome way of securing your application with passwords.
                  5. Plugins.
                  6. The $-minded community.

                  I had some knowledge of Alpha Five v1 from back in 1995. In 2003 I started again to explore this program and picked up the thread with A5v5. I never regret it.

                  I love programming languages in general and this database has a very strong language: Xbasic. Besides that it has a dialog builder language: Xdialog. However you can build a database and never use xbasic or xdialog but if you want to use MySQL you will need Xbasic. Maybe that future versions will have genies that hides the xbasic stuff.

                  If you need a function and you cannot find it in the huge function collection of Xbasic you can build your own DLL and call your function from Xbasic in a simple way and much easier than building a plugin for FM. Calling Windows API functions is also easy.

                  When it comes to building your application I think you will have to redesign it from scratch. Alpha has a lot of different stuff to do data handling different than FM. Study how Alpha handles things. You can do a lot more with the interface, also some things less but you don't miss them, than in FM.

                  Start examining the Alpha Sports database, start small and as others also told you, look at the example videos.

                  But be aware, all that glitters is not gold.

                  Welcome to the Alpha Five community!
                  Marcel

                  I hear and I forget. I see and I remember. I do and I understand.
                  ---- Confusius ----

                  Comment


                    #10
                    Re: FMP to A5 - concerns...

                    Thanks for all the great comments. I guess I'm just going to have to bite the bullet and start studying. I know in the end it will be worth it, that's obvious, it's just hard to leave something that you know so well. I can be very productive with FMP to a particular level of complexity but ... too much frustration after that. Thanks again.

                    Comment


                      #11
                      Re: FMP to A5 - concerns...

                      Hi William --

                      One approach is to take a small piece of your current application and try doing it in A5. I made the transition from Access rather than from FM. I have an apartment management system that I have developed over the past three years.

                      I started with the workorder part of it, a functionality that previously took me six months to get working properly in Access (partly because it took me awhile to figure out how to split the Access application from the Access code - something done routinely in A5.) I reproduced the workorder system in a weekend in A5, and learned a lot about how to put things together in the process.

                      -- Dick James

                      Comment


                        #12
                        Re: FMP to A5 - concerns...

                        breakup the test forms into their own tables
                        If I'm interpreting this correctly, what you said here is not necessary. All layouts (forms, reports, letters, labels) are "attached" to their associated table or set but they are in separate files called data dictionaries. (Lookup up "data dictionary" in the Help file.) As a result, file size probably won't be an issue and you certainly do not want to start getting into some strange attempt to separate forms from their respective tables - Alpha is not really designed to do that easily.

                        I couldn't find a listing of data dictionary files in the Help file (but I'm pretty sure it's in there somewhere) so here they are:

                        For TABLES:
                        - the dictionary files have the following extensions: .ddd, .ddm, .ddx
                        - dictionaries contain field rules, layout definitions, and a few other things but not data.

                        For SETS:
                        - the dictionary files have the following extensions: .set, .sem, .sex
                        (HINT: Don't let someone clean up the "sex" files as one of my customers once did!)
                        - these dictionaries contain the set definition and all layouts related to the set. Field rules are still in the dictionaries of the individual tables. (You can enter/edit field rules from within the set but you are really only changing the field rules in the respective tables.)

                        For the DATABASE itself:
                        - the dictionary files have the following extensions: .alb, .alm, .alx
                        - these dictionaries primarily contain the global scripts and functions but also various settings, the network optimize version number, and a few other things.

                        (Hmmm, I think saved search definitions are also in the table/set data dictionaries.)

                        Comment


                          #13
                          Re: FMP to A5 - concerns...

                          Cal, perhaps you were thinking of the help file topic "Alpha Five File Types" ?

                          Comment


                            #14
                            Re: FMP to A5 - concerns...

                            I just wanted to clarify one item in this thread.

                            Alpha Five v8 web applications can currently be built against the native .dbf database engine OR against live SQL backends such as SQL Server, Oracle, MySQL, DB2 etc (including support for Portable SQL)

                            Alpha Five v8 desktop applications can be built against .dbf files and desktop xdialogs can be built agains live SQL backends. Forms at this stage can be built against "snapshots" of SQL backends through "passive links" but not directly against live SQL data ie "active links".

                            The upcoming major release of Alpha Five is expected to offer "active links" for desktop applications which means the native .dbf can be completely replaced by a SQL backend if users prefer that.

                            Another point to note since this thread relates to a "convert" from the "church of FileMaker."

                            Since a key reason to use a SQL backend is to get added computing power, scalabilty and speed. This is achieved by using "client server" architechture where core database functions like sorting and searching happen on the server at the database engine (ie SQL backend) level, because that is what these engines do really well. The result set is then passed onto the client application for formatting and layout etc. For reasons that are a little curious to us, Filemaker's recent release 9 which touts SQL support does not appear to follow a proper client server approach and Filemaker expects the heavy database lifting (such as sorting and searching) to be done at the client level?? which sort of defeats the whole benefit of going with a client server approach. In situations where the backend database is small - this is no big deal - but with larger files, the Filemaker solution becomes painfully slow.

                            The Alpha Five implementation will take full advantage of the comptuing power of SQL database engines on the server.

                            If anyone is interested in a technical whitepaper published by Filemaker on this subject (where they caution against using FM as a front end to large SQL databases,) email me please at [email protected]
                            Richard Rabins
                            Co Chairman
                            Alpha Software

                            Comment


                              #15
                              Re: FMP to A5 - concerns...

                              Originally posted by Tom Cone Jr View Post
                              Cal, perhaps you were thinking of the help file topic "Alpha Five File Types" ?
                              Thanks Tom, that's it.

                              (Interestingly enough, using that exact text as a search, an Index lookup won't find it unless you restrict the lookup to "Alpha Five" and a Search shows it as rank 15. However, if you look up "data dictionary" as I did, it's ranked 8 - go figure. It does get better if you put quotes around it but even then it's still only ranked 3.)

                              While re-reading that Help topic I noticed that it refers to only the DDD, SET, and ALB files as the "data dictionaries", I think it would do most people good to consider all 3 of each as the data dictionaries - ddd, ddm, ddx // set, sem, sex // alb, alm, alx. It has always been my policy, and I think most developers agree, to copy all 3 together.

                              Comment

                              Working...
                              X