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

Alpha recommends SQL rather than DBF - opinions please ....

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

    Alpha recommends SQL rather than DBF - opinions please ....

    In alpha's most recent newsletter, alpha's position is clearly stated:

    "We don�t recommend using Alpha�s native DBF format database for Web applications, either, primarily for scalability reasons. Instead, we recommend using a SQL database."

    It has been my impression that most of us use DBF files - some of course are using SQL, but I think most use DBF.

    In light of alpha's clear position, what do you all think about this?

    Are you planning to migrate?

    How difficult would it be to migrate an application? Would all the scripts, forms, dialogs, etc still work?

    What would be the benefits? No index corruption has been mentioned.

    Alpha mentions that the main benefit would be "scalability". What does that mean? Size of application? Number of simultaneous users? What?

    What about security?

    Speed?

    If we use DBF's is there a pragmatic limit on number of simultaneous users? Would that be significantly enhanced with SQL?

    Am I the only one who wonders about this??

    Gary
    Gary S. Traub, Ph.D.


    #2
    Re: Alpha recommends SQL rather than DBF - opinions please ....

    Hi Gary

    I have thought about this as well. I am currently using dbf's. Mainly because it is just easier. Several of my apps are hybrid and while that is possible with SQL Engines - it is REALLY simple with the dbf's. That being said, it seems easier just using a straight web app IMHO. I remember reading somewhere here there is a point where the difference between dbf's and SQL databases is noticeable. But, that is somewhat ambiguous in and of itself. I also remember reading that dbf's will be faster until you get to a point of a BUNCH of records - 200K plus records or so if I remember correctly.

    I know the SQL route is supposed to be more secure / scalable but unless you are purposely building a HUGE app I don't see the need at this point. Just my 2 cents........

    Regards,


    Jeff

    Comment


      #3
      Re: Alpha recommends SQL rather than DBF - opinions please ....

      Gary,

      I have been giving this thought as well. I have an application with about 20 tables and lots of grids, dialogs, and reports. It would be a pain to update them all.

      I have created a few active link tables used for linking to external systems, and they work very well, but everything else is still in DBFs. I remember reading in one thread that Alpha may release an "upsizing" wizard to convert DBFs to active link tables. I have been waiting to see if that happens. I have also read other threads that seem to discourage using active link tables for your entire application (overhead issues?).

      One specific question that I have (and have not run across an answer to) is; are active link tables still subject to the 2GB limit that standard DBFs have? As I understand it, they still contain a copy of all the data.

      -Paul

      Comment


        #4
        Re: Alpha recommends SQL rather than DBF - opinions please ....

        are active link tables still subject to the 2GB limit that standard DBFs have
        Paul,

        I would not think this is the case since SQL database can be enormous...and Alpha is not controlling their backend structure- just the entering/editing of data. This would make the active link table thing kind of limited if there was something like that imposed on it when Alpha is targeting enterprise apps with some of their marketing.

        Regards,

        Jeff

        Comment


          #5
          Re: Alpha recommends SQL rather than DBF - opinions please ....

          Jeff,

          I am hoping that you are correct. I can't tell if they mean that you should be connecting directly to the SQL data sources or if it is OK to use active link tables everywhere.

          I also use a lot of operations and scripts that run from a desktop console. So I don't think it would be easy to use data sources everywhere, it would really make sense for me to just convert all my tables to active link tables (if everything would still work, and performance would not suffer).

          Thanks,
          Paul

          Comment


            #6
            Re: Alpha recommends SQL rather than DBF - opinions please ....

            Thanks guys for your comments.

            Overall, I am still wondering how difficult it would be to use SQL tables, after already creating an application with DBF's. Would all the grids, dialogs, Xbasic scripts still work. What about tbl.query_create's to retrieve data. Would all those have to be changed to SQL syntax, or does alpha handle all of that for us. What about things in our DBF tables themselves, like autoincrement fields, calculated fields, etc.

            Gary
            Gary S. Traub, Ph.D.

            Comment


              #7
              Re: Alpha recommends SQL rather than DBF - opinions please ....

              Grids seem to be easy to convert esp. to mySQL SQL queries, same for desktop active link tables (as long as you use Alpha5 to generate the tables through export operations, then create active link tables against the mySQL database and copy the forms over).

              Comment


                #8
                Re: Alpha recommends SQL rather than DBF - opinions please ....

                Thanks Andrea. That provides some insight into this. Based on your experience, how much work is involved in converting, and what are the basic steps?

                Gary
                Gary S. Traub, Ph.D.

                Comment


                  #9
                  Re: Alpha recommends SQL rather than DBF - opinions please ....

                  Originally posted by drgarytraub View Post
                  Thanks Andrea. That provides some insight into this. Based on your experience, how much work is involved in converting, and what are the basic steps?

                  Gary
                  • Set up mySQL or whatever database you are using
                  • Read up basics on SQL syntax for your chosen database
                  • Ensure your development and server machines both have access to the SQL database
                  • Build SQL AlphaDAO connection string in your Alpha5 database
                  • Create export operations for all your dbf tables, to generate the tables in the SQL database
                  • If you use non-numberic ID fields, you need to define the primary key for each table you have non-numeric IDs for. (Consult your SQL database documentation)
                  • For desktop apps, create active link tables for each DBF, then copy the forms and reports over from the DBF versions
                  • Convert any queries or filters you may be using for desktop tools and scripts to SQL syntax
                  • For web, make a copy of each component that uses DBF files (I usually name them component_sql), open the component and select AlphaDAO instead of DBF, follow help file and tutorial instructions if you have problems converting basic syntax
                  • In your publishing profile, go to AlphaDAO connection strings, open your connection string and click "Copy Default" (Without this for some reason it will not work)
                  • Convert dbf queries and scripts to use sql_ functions - again consult help files, What's New in V9 pages and tutorials

                  Comment


                    #10
                    Re: Alpha recommends SQL rather than DBF - opinions please ....

                    Thanks Andrea. That is very useful!

                    That seems like a lot of work. Is it as much as it seems?

                    Gary
                    Gary S. Traub, Ph.D.

                    Comment


                      #11
                      Re: Alpha recommends SQL rather than DBF - opinions please ....

                      Originally posted by drgarytraub View Post
                      Thanks Andrea. That is very useful!

                      That seems like a lot of work. Is it as much as it seems?

                      Gary
                      Only getting your head round the SQL part is "hard" - depending on which database you use etc. I have found it incredibly easy to convert all my DBF based web stuff to mySQL and it has been a heck of a lot easier to maintain data-integrity wise because you a SQL data source remains in place and you don't get the problem of having to download DBF files and publish them again/overwriting data etc.

                      Comment


                        #12
                        Re: Alpha recommends SQL rather than DBF - opinions please ....

                        Andrea,

                        Thanks again. I have a much better feel for what would be entailed, and where to go from here. :D

                        Gary
                        Gary S. Traub, Ph.D.

                        Comment


                          #13
                          Re: Alpha recommends SQL rather than DBF - opinions please ....

                          Hi Gary,

                          like Andrea I am a convert to using SQL database , I use Oracle and find it very refreshing that when I tell that the application uses an Oracle DB backend, people tend to have more respect towards the application than telling them you are using DBF files ( which I have to explain back to foxpro databases...). Now the only thing I have to explain is the Xbasic part...For some reason Java seems to be hotter..

                          One of the things to keep in mind is that you cannot use the Alpha field rules like autoincrementing ID numbers. In Oracle you will have to define Sequences on the particular field to get the same result. Which means you will have to digg deep into how to accomplish this in your particular SQL DB system.

                          Overall I think it's worth investigating using standard SQL databases compared to the native DBF system. Alpha mentions scalability. Also there are a lot of tools out therre specifically dealing with databases (like TOAD) which are available when you use a standard DB. Maybe portability is another one. If you have your application using a standard database you are also more open to any future application development system when something hits the market which is better or offers more than Alpha. Until now I did not find one. And this includes Morfik...It's not just good looks which count in DB applications... regards,Ron
                          Last edited by rleunis; 12-18-2008, 05:17 PM.

                          Comment


                            #14
                            Re: Alpha recommends SQL rather than DBF - opinions please ....

                            Originally posted by rleunis View Post
                            Hi Gary,

                            like Andrea I am a convert to using SQL database , I use Oracle and find it very refreshing that when I tell that the application uses an Oracle DB backend, people tend to have more respect towards the application than telling them you are using DBF files ( which I have to explain back to foxpro databases...). Now the only thing I have to explain is the Xbasic part...For some reason Java seems to be hotter..

                            One of the things to keep in mind is that you cannot use the Alpha field rules like autoincrementing ID numbers. In Oracle you will have to define Sequences on the particular field to get the same result. Which means you will have to digg deep into how to accomplish this in your particular SQL DB system.
                            Hi,

                            I am less of a convert and more of a "native" in a way, although our Oracle database is very outdated... unfortunately. We used to have an IT budget ;)

                            I do actually think there is a whitepaper on sequences and Oracle/Alpha, and I seem to recall that with Alpha-generated tables Alpha5 does or is supposed to generate the sequences automatically.

                            By the way what version Oracle do you use? I'm happy to see another user with an Oracle background :)

                            Andrea

                            Comment


                              #15
                              Re: Alpha recommends SQL rather than DBF - opinions please ....

                              Originally posted by NoeticCC View Post
                              Hi,

                              I am less of a convert and more of a "native" in a way, although our Oracle database is very outdated... unfortunately. We used to have an IT budget ;)

                              I do actually think there is a whitepaper on sequences and Oracle/Alpha, and I seem to recall that with Alpha-generated tables Alpha5 does or is supposed to generate the sequences automatically.

                              By the way what version Oracle do you use? I'm happy to see another user with an Oracle background :)

                              Andrea
                              Locally on my PC I have Oracle XE 10g which |I use to create the prototype and the project at client is converting from oracle 8 to 10G also...Consolidated database. Means a lot of different schemas in one DB.
                              The final project will deliver an application which will be based on Oracle 10G DB with application developed in Java, with Wicket, Hybernate against Oracle..


                              I am interested in the white paper...Can you share?
                              regards, Ron

                              Comment

                              Working...
                              X