Why second rate controls for A5v8 users?

[Peter.Greulich]

Re: Why second rate controls for AF8 users?

FYI: Your example has the hz. splitter turned off.

In any case i believe Bob is asking about a non-browse spliiter.

[G Gabriel]

Re: Why second rate controls for A5v8 users?

FYI: Your example has the hz. splitter turned off.

What hz splitter?

In any case i believe Bob is asking about a non-browse spliiter.

I am aware of that, maybe you missed it.

[Peter.Greulich]

Re: Why second rate controls for A5v8 users?

What hz splitter?


I am aware of that, maybe you missed it.

The browse hz splitter.

Yes, i did miss it. Perhaps you could point it out.

[Thontlb]

Re: Why second rate controls for A5v8 users?

"I just bought AF8 enterprise because of its "faster than Access" claims and its "improved" form design capabilities. On the latter, I'm a more than a little disappointed"..............................

I actually found some design improvements or found some that were already there that I wasn't aware of. Seriously, V8 is a major update and I have been one of the major critics of alpha. V8 is significantly faster than V7 although that only means that it's not as slow as it was. It is and hasn't beeen anywhere close to as quick as access V2 of MS. I ran an identical (indexed equally and criteria) queries retrieving 15,000 zip codes with Access 2003 vs A5 V8. Access retrieved and dsiplayed the form 3 seconds faster than A5 in V8 and almost 6 seconds than V7. Access uses compiled SQL queries which along with the faster screen rendering of Access especially for controls which use sql as a recordsource (combo, list, etc.) it's going to blow A5 away. A5 is fast enough for me and most average users, but the "faster than access is a myth. It's faster than Filemaker.....................
My only problem with A5 is the lack of SQL when using native dbfs.

[csda1]

Re: Why second rate controls for A5v8 users?

It is and hasn't beeen anywhere close to as quick as access V2 of MS. I ran an identical (indexed equally and criteria) queries retrieving 15,000 zip codes with Access 2003 vs A5 V8. Access retrieved and dsiplayed the form 3 seconds faster than A5 in V8 and almost 6 seconds than V7. Access uses compiled SQL queries which along with the faster screen rendering of Access especially for controls which use sql as a recordsource (combo, list, etc.) it's going to blow A5 away. A5 is fast enough for me and most average users, but the "faster than access is a myth.

I'm not doubting that given any particular set of testing that you may have found Alpha slower than something else, but let's make sure you are not talking Apples and Oranges.

Were you using Alpha 5 with SQL access the same as Access? Or were you effectively using SQL for Access, and DBF file formats for Alpha 5. The MySQL is one of the fastest (if not the fastest) for Alpha 5, so were you using one of Accesses fastest against one of Alpha 5's slowest dialects of SQL?

If using the DBF format, did you make sure LQO was invoked? And when you said 3 seconds faster than Alpha 5 v8, was that out of a total of 6 seconds or 600 seconds? We can't read the percentage differences without that info. And what part of that was the access to the records versus the form display?

What version of Access are you using precisely? If you are using an old version of Access, then it probably doesn't have the same overhead for some things that the newer, more capable versions might have. It's like comparing Word 1.0 to Word 2007 and saying it runs faster. True, but can it handle the same range of abilities?

And one must be careful to optimize for each language, not just assume one or the other is faster. Alpha 5 consistently beats most other environment's in Development time, and comes reasonably close or faster for probably most operations. Badly written applications in Alpha 5, Access or other programs can bring any system to their knees, well written ones should never do that.

[forskare]

Re: Why second rate controls for A5v8 users?

Well said Ira! I don't think Selwyn could have said it any better! There's a lot to consider when running a test comparison.

kenn

[Thontlb]

Re: Why second rate controls for A5v8 users?

I used Access 2003 loaded with add-ins. Same table, indexes fields for both. Just City, State & Zip code fields. Primary Key zip code. You make a good point that I compared Access native SQL Query against an A5 query operation, but that's the default. I'm comparing them as the run out of the box. Most new Alpha users are going to make dbf tables and won't be using odbc and mySQL. LQO should have by default been invoked by virtue of the primary key. The comparison was made as if the boxes were opened the default features used.... simple dbf table and a simple access table on an .mdb database. I've only used A5 with dbf's and am proficient with the correct indexing to maximize the "Lightning Fast Query" They each only had the one primary key which is all that's nec. From the Database window, when I press the show form button is where I started timing, so screen rendering well could have and probably is the difference. Both apps already were running everything needed ready to display the form.

A newbie might be able to make a simple application up and running faster with A5, but they both have so many wizards and macros that even that's debatanble.

The PC is a P4 3.4 with 2 gigs of RAM. I really do think Alpha is a great program, but as a user of both Access and Alpha, I know that Access is faste r it bothers me when the "faster than Acccess claims" keep coming around. Screen rendereing has always been slow in A5 so the data retrieval might be close to or the same.

V8 is a good solid upgrade. I didn't consider V6, 6.5 or 7 upgrades....they were income generators.

[Thontlb]

Re: Why second rate controls for A5v8 users?

BTW..In access, I always use the autoincrement (integer) field for the pk. In Alpha, I use a 6 digit character autoincrement. There are now enough "pluses" in V8 to make it close to worth making my app with it. The biggest setbacks are still that there are no code no modules. the Access database control panel is neatly organized and my procedures and functions are easily found. Alpha's database window is still a jumble of code that I can put into more jumbles of libraries if I choose to. I use naming conventions to keep my sets and tables organized as best as I can, but the code page is a lost cause. And with the FMS third party addins, I'm back to Access. No app is so good that it doesn't need add-ins to help it out. Alpha's anayzer and the attempt at a third party one are not of much value, but granted FMS has had several years jump time and the support of microsoft in making theirs.

I supose that until or if Alpha's customer base grows large enough to make third party assets profitable, there won't be any.

[Peter.Greulich]

Re: Why second rate controls for A5v8 users?

V8 is a good solid upgrade. I didn't consider V6, 6.5 or 7 upgrades....they were income generators.

With regard to that particular statement, it would be accurate to say that v6 was a major upgrade for web developers, since that's where the WAS was introduced. And V7 was a major WAS upgrade.

[Thontlb]

Re: Why second rate controls for A5v8 users?

Granted, I look at A5 from the desktop point of view. The problem with upgrading one major portion of the program but not the other is when Alpha dropped support for a version it forced desktop users to buy unneeded WAS upgrades without any benefit for their buck.

[Thontlb]

Re: Why second rate controls for A5v8 users?

You are correct, Ira, but I think the test could not have been any closer in comparison with default "out of the box" promoted features. The biggest difference in the query is the character pk vs integer key in Access, but that seems to be how most a5 users key their table unless they've written a custom incrementor. I've been whining about Alpha for years now and I think V8 is finally something that I can come close to Access with. I got spoiled using Alpha for DOS and the ease of generatoing custom application. It all changed with Windows.

One remaining major drawback is still not being able to have unbbound forms and having to use xdialog for custom dialogs unless one uses a dummy table.

I've found xdialog overwhelming in trying to format dialogs via code.

[Peter.Greulich]

Re: Why second rate controls for A5v8 users?

Granted, I look at A5 from the desktop point of view. The problem with upgrading one major portion of the program but not the other is when Alpha dropped support for a version it forced desktop users to buy unneeded WAS upgrades without any benefit for their buck.

Agreed

[APFCClyde]

Re: Why second rate controls for A5v8 users?

You might want to take a look at this thread for what one developer has done graphically with A5 V8:

http://msgboard.alphasoftware.com/al...d.php?p=403666

[Richard Rabins]

Re: Why second rate controls for A5v8 users?

Clyde thanks for finding the thread you located.

[Richard Rabins]

Re: Why second rate controls for A5v8 users?

You might want to take a look at this thread for what one developer has done graphically with A5 V8:

http://msgboard.alphasoftware.com/al...d.php?p=403666

BTW we have spoken with Amanita (the Alpha Five developer who created these good looking apps) and she is considering creating some video tutorials on design approaches to help Alpha Five developers make their applications look super professional with the new design tools available in Version 8. How does that sound?

Regards