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

PostgreSQL vs FirebirdSQL in Windows Desktop Applications

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

    PostgreSQL vs FirebirdSQL in Windows Desktop Applications

    Last week I started a small XBasic script project to prove to myself that I could accomplish what I wanted to accomplish with Alpha Anywhere. I am currently evaluating AA for purchase and I have over 15+ years experience developing in Visual Foxpro. The script needed to create a temporary DBF table, import data from a CSV file into the temporary DBF table, then make a SQL connection to a backend database, loop through the DBF table, issue a Select query to determine whether the next step for the script is to INSERT a new record in the SQL database or compare each field in the record to the ResultSet to locate any required updates and submit them to the database. The processing included using a WaitDialog to update the user on the progress and the clean up included deleting the temporary DBF file when the process finished.

    I initially tried to use FirebirdSQL as the backend database and became concerned that some of the problems might somehow be related Firebird. So, I switched to PostgreSQL as the back end database and discovered that the problems were with the logic and not the databases. So when I got the script working with PostgreSQL, I decided to see if Alpha was really SQL portable and so I switched back to the FirebirdSQL backend. The switch between different Named Connections was flawless and required NO CODE CHANGES to switch database engines.

    My next thought was to try and do some benchmarking to compare PostgreSQL and FirebirdSQL and I thought someone here might want to see my results.

    The full description of the script project and the working script itself can be found here:

    http://msgboard.alphasoftware.com/al...es-amp-inserts

    Using the exact same code published above and changing only from the native AlphaDAO PostgreSQL Named Connection to an AlphaDAO ODBC Named Connection to FirebirdSQL and both database engines were downloaded and installed using the default out of the box settings with no tweaking. I ran three tests on both database engines and came up with the following results:

    Code:
    498 Records Processed	                  PostgreSQL	FirebirdSQL
    Empty Selects & All Inserts	          01:17.3	00:25.8
    All Selects Tested; No Updates       	  01:42.6	00:55.2
    39 Inserts & 20 Field Updates	          01:39.5	01:04.9
    FirebirdSQL was the clear winner in this small, unscientific performance test. I'm sure the difference is directly related to PostgreSQL's ACID compliance, but the most interesting result to me was the second test where all we did was a single select statement to test all records for any required updates. No changes were written to the table in this test, so what we are seeing is the pure time it takes to select 498 records one at a time and then comparing each field within our temporary table to the SQL ResultSet and then move on to the next one. Amazingly, PostgresSQL was 47 seconds slower than FirebirdSQL. Again, all we were performing were reads, string comparisons and no writes. FirebirdSQL slows down a bit when we do the mix of 39 inserts and 20 field updates but only about 10 seconds, but PostgreSQL actually ran slightly faster with the inserts and updates. When performing all inserts, it wasn't even a race as FirebirdSQL was almost 3 times as fast.

    Not sure if anyone cares about this type of comparison as many of us are happily committed to our favorite database engine and I'm sure that tweaks could be made to optimize different systems and that your mileage will vary.

    But, if you are posting large quantities of data to a SQL database, FirebirdSQL is a great choice if you are interested in high speed inserts and updates.

    I would like to hear from both PostgreSQL and FirebirdSQL proponents to hear your thoughts on the subject of which database engine is better. I'd even like to hear back from those using other SQL engines to get your takes as well.

    Thanks!
    PT
    Paul H. Tarver
    Tarver Program Consultants, Inc.
    www.TPCQPC.com
    www.TPCDataWorks.com

    If you are doing today, what you were doing three years ago; you are backing up, not standing still.
Working...
X