One more v5 patch, please

[CALocklin]

RE: One more v5 patch, please

Ray,

I agree with you in principal. However, I'm not even concerned about just full blown bugs. I'd like to see a list of "time wasting issues" that could be fixed. I'm sure there are plenty and many have been carried over into v6. In fact, I'm starting to build a list of my own.

Your import issue could be one of these "time wasters." Even if you find that there is a problem in your script, it would save someone else a lot of time if A5 would issue an error message rather than just closing down. However, the first problem is to determine what is causing it to shut down. Please let me know if you ever figure out what that problem is.

Don't take this wrong. I'm not faulting Alpha for this type of issue because (a) things like this are bound to happen and (b) they often are not reported because there is either no proof it's a bug, no simple answer, no obvious solution, it's not easy to repeat, or the developer just didn't take the time to report it. I would just like to see these things "fixed/improved" so someone writing an application doesn't have to waste a few hours trying to find the problem or find a work-around. "Fixed/improved" could mean truly fixed if it's a bug, or improved if it's just an annoying time-waster, or some type of error message/warning could be provided. Too often this type of issue is something that an individual developer might encounter so rarely that, even though they had seen it before, they forgot what the solution was and end up wasting time again.

If anyone else has examples of this type of thing, please let me know or post it here. If possible, identify whether or not the issue also occurs in v6. I'd rather get a list of possible issues then have a few good developers review them to verify that they are real rather than inundate Alpha with all kinds of very minor or invalid issues.

Cal Locklin
www.aimsdc.net

[Thomas Jones]

RE: One more v5 patch, please

Amen

[martinwcole]

RE: One more v5 patch, please

Cal, the biggest time waster that I have is in designing reports when there are subreports. The editor has some refreh bugs that more or less force me to repeatedly close and then reopen the report when I am making design changes.

I haven't got version 6 yet. I may be incorrect, but other than the web browser, there don't seem to be enough changes to warrant the expense. Also, it would cost me more to upgrade to 6 for 1 full and 10 runtime than it did to upgrade from 4.5 to 5. I wish they would add some of the new functions., etc., fix a few bugs, and make a 5.5 upgrade. I suspect that would sell a lot of copies, as there are many of us who have clients still using 98/ME.

[Rawlings]

RE: One more v5 patch, please

Hi Peter Greulich,
Sorry for the misunderstanding. I noted in your reply that you don't use refrential integrity, if this is true, don't you use SET in your database & if you do use SET, how do you get new parent/child linking key record created at the parent level to be equally created on the child level. It has never worked for me in A5V5. Another problem I also have with A5V5 is the prevalent dropping of indexes even though my indexes has nothing to do with variables that may or may not evaluate to trigger A5 to drop it. Thanks.

RAWLINGS

[Peter.Greulich]

RE: One more v5 patch, please

Martin,

I haven't got version 6 yet. I may be incorrect, but other than the web browser, there don't seem to be enough changes to warrant the expense.

I agree. v6 is a web product w. a relatively few enhacements for "the rest of us".

I wish they would add some of the new functions., etc., fix a few bugs, and make a 5.5 upgrade. I suspect that would sell a lot of copies, as there are many of us who have clients still using 98/ME.

Me thinks that you are correct.

Peter

[Peter.Greulich]

RE: One more v5 patch, please

I'm not sure i follow you. But if you are saying your child records won't link, that doesn't make sense (i guess). Check out the attached sample set. The childs link okie-dokie.

[russ Boehle]

RE: One more v5 patch, please

Sets work fine in v5. You don't need referential integrity and in most cases will cause yourself problems by using it as it seems to cause a bunch of problems.

Creating a record in a parent does not mean that there by default will be a record created in the child. You, of course can do this with xbasic or action scripting but it is not necessary. The set just relates, or connects two tables related by a common key value.

I use sets all the time for forms and reports but stay clear of referential integrity. To create a child record I usually bring up a child form and enter the key value from a variable set from the parent before the child is opened. This is much more reliable and faster in a busy network environment.

Russ

[russ Boehle]

RE: One more v5 patch, please

Add me to the list. I may go to v6 eventually but also have the win98 gotcha. I don't really expect a v5.5 (althought it would be nice) but one more patch would be nice. Of course then everyone would be asking for one after that and so on. Even better would be making v6 win 98 compatible and making the upgrade really cheap if you promised never to use it for web development ;-)

Russ

[LEGRAN]

RE: One more v5 patch, please

Raymond,
I also am having a lot of little "bugs", and I know these are bugs because they have bugged me so much that I have gone back to A5V4. I posted my problems last week but got no sympathy. I have field rules (calculation; qty x selling price = ext_price) that works most of the time, but not all the time. Example of error; 6 x $6.50 = $0. This error along with 5 others on one order was caught as the order was being shipped. I have had 4 orders now that had similar errors.
Ctrl-enter and ctrl-shft-d are also very erratic.
I could not understand why our inventory was coming up short until I caught a posting rule working only most of the time. I could go on but I think you might get the picture. I do not understand why others have not had or posted similar problems.
I have been using Alpha products way back to the earlier DOS products and A5V5 has not been a pleasant experience.
I upgaded to a new computer (XP, etc) for the trial version of V6 and had some of the same key press problems in V6.
I'm for a 5.5 upgrade , but only if it's a freeby. V5 was not worth my time.

[Peter.Greulich]

RE: One more v5 patch, please

I think your unhappy experience w. v5 is fairly unique. My experience is just the opposite. Overall I have found that v5 is FAR less buggy than v4, of course, there are always exceptions. For most of us, I think, v5 has been great.

[JerryBrightbill]

RE: One more v5 patch, please

While no program is perfect, A5v5 has indeed proven much better than A5V4, which didn't really have that many problems. Issues with browses are well documented and Selwyn has posted more than once that the only solution to any of them is a complete rewrite of browses. The current design dates back to A5V1, which was rather buggy. The new browses were demonstrated at this years conference and initially look very good, but I am sure they want it right. They were intended to be in V6, but apparently didn't make the deadline.

One observation I feel must be made. I have seen many posts about so called bugs that were actually coding errors by the user. Sometimes they are not recognized as such and the program gets blamed. There have been a number of times I thought the program was in error and later learned that I had made a slight code error that caused the behavour. While I agree with Cal that it would be nice if the program trapped all such errors, that is just not possible. For example, V5 trapped errors that A5V4 ignored. Now A5V6 traps even more errors. Already, some users have reported the new errors as bugs, since their V5 version seemed to work. In fact, V5 may have just ignored the error, but it was still an error in the user code, not an error in the program.

Whenever I find what I think is a bug, I try to establish a consistent way to duplicate it, step by step. Unless I can find a way to exactly and consistently recreate the problem, there is not way to isolate the issue. In the process, I frequently find the source of the issue, and most often it is me. If I can duplicate a program error, I record the information and send it to Alpha. Of all of the real bugs I have ever reported, and there have been many, only a very few minor issues were never addressed. Nearly all of them relate to browses. I found one that has existed since A5V1 and still exists in V6. From the information I got back from Alpha, I am the only user who ever found or reported the problem. Since I have a workaround, it won't be fixed and I can live with that.

Now, just for fun, report a bug in Word to Microsoft and see what the response you get - none. If you have a problem that isn't in their literature, you have to pay to get any solution, if there is one at all. We can complain all we want about fixing bugs, but I have never seen any software company respond as well as Alpha. At the same time, with the new version in production, I would expect minimal fixes to older versions.

A great example is a lookup bug that existed in the last build of A5V4.5, build 266. There was an unreleased build, build 267, that fixed the problem. Why wasn't it released? I suspect because The fix was added to A5V5 and only a handful of people ever found the problem in V4.5.

It isn't Alpha fault that we don't want to spring for the new version, or are stuck with Win98 and can't upgrade. I expect them to make the current version as bug free as possible, but I don't expect them to continue development of V5.

Jerry

[Stephen Williams]

RE: One more v5 patch, please

I agree with Jerry.

I am running win98 and will not upgrade before I get a new OS, may be a while. The browse refresh drives me nuts, but I am used to it. If this was fixed in V6 I would upgrade much faster. So long as they are working on it I do not want them spending time on V5. I have no need of web based stuff, though I know of folks could use this. What I hope is the web stuff does not get in the way of fixing these basic level "bugs".

I would also say Alpha Software has advertised a lot as a powerful program for non programmers. Unfortunately you need to be a programmer to deal with the bugs, and non programmers will rush to cry "bug" rather than critique the code, which is mostly over their head.

My point in this post is simply to voice my personal preference: Keep Alpha Software programmers on the cutting edge, but also adding depth at that cutting edge. Fixing the browse issue is huge. Do it on the next build, but make a version for us folks that don't need web.

It was always my hope that Alpha would raise their price (they did this right IMHOP) then plow that cash flow back into the product and marketing. Alpha is gaining ground but I don't get the feeling they are sufficiently established to stop pushing that cutting edge and I would rather they stay focused.

[Peter.Greulich]

RE: One more v5 patch, please

I don't know if Alpha is fixing the browse or not. I heard directly from them a long time ago that it would be in ver. 6. Then later, I heard directly from Alpha, that it would not be in v6. The browse should have been rebuilt for v5. It should have been their TOP priority. My concern is that w. v6 and its powerful web capabilities (you don't need a "browse" on the web), it may just get left behind once again. They ought to rebuild it and offer it (as an upgrade if need be) in both v5 & v6. Since Alpha is mute on this subject we may never know what their plans are. Promising it for v7 is a non-starter for me (after all, they promised it for v6). I think we would all love to here from Alpha about this.

[CALocklin]

RE: One more v5 patch, please

Jerry,

I didn't mean to imply that all errors should be trapped. Yes, it would be nice but I don't think it would be reasonable.

In the case of error trapping, I'd just like to see errors generated for those things that are known errors (even some that could be called programmer errors - see examples later) and that have been encountered by more than one person. This type of error can waste a lot of development time.

NOTE: Part of the problem is our own if we don't make the issues known to Alpha and I think many of us have fallen short here because of the assumption that the error must be ours if we can find a work-around. Part of the problem can be Alpha's if the response is "here's the work-around" [with it's implied: try to remember it when you run into this issue again 10 months from now.]

Examples:

Setting indexes for tables in xbasic.

If you set the index as
tp = table.open("MyTable")
tp.index_primary_put("Last_name_")
but there is no index named "Last_name_" and there is an index named "Labor_ID_" (same first letter), the system will set the index to "Labor_ID_" without warning you. If there is no index with the same first letter, I'm pretty sure the system does nothing (maybe uses the record number index?) but does not warn you. Alpha fixed this for FORMS with the .Index_SetVerify function but there is still no fix for this when setting indexes on tables via xbasic. If you want to verify an index setting, you must create your own routine to check it.

The developer could be blamed for not typing the correct index name but certainly A5 should be able to trap something like this. Also, what happens if the index is lost or deleted? That isn't necessarily a developer issue.

RESUME &gt

This isn't really something that should generate an error message but it is an example of a problem that has a simple work around once you know what the issue is but you can waste a lot of time figuring that out. (The problem I have with all of these issues is not that they exist but that they can waste a lot of development time.)

This one has been a long standing thorn in my side. The "resume label" command will always skip the first real command (not just the next line that was typed) after the label. This means that every label that might be accessed with the "resume label" command must be followed by some useless command like 1=1 or the script won't run as it should. I have this well documented.

Apparently, like your situation, I'm the only A5 user in the world who has ever used this command. Everyone else seems to prefer typing 10-15 additional lines of code to set variables and uses a RESUME NEXT then jumps based on the variable setting rather than using this command. (Strange - this command has been used in many other languages; why don't any A5 developers use it? Maybe because it doesn't work properly?)

If, in fact, nobody else is using this command then I have no problem with Alpha leaving it as-is. In fact, I'd encourage them to remove it and I will change all my scripts that use this command. (There aren't many and I have search routines that will find them quickly.) Better to not have the command than to have one that doesn't work correctly. Otherwise, some unsuspecting new user might actually try to use it in the future. (Sorry, I'll get off my soap box now and, under the assumption that I'm the only person in the world who has used the RESUME "label> command, never bring this issue up again.)

Cal

[JohnZaleski]

RE: One more v5 patch, please

Cal,
The index issue was brought up a long time ago - several versions ago - I was very surprised to see that also. Problem with fixing something like that and making it bomb out is that all of a sudden someone does an update and a long standing script no longer works the way it did before. This falls into the umbrella of backwards compatibility - it's not always black and white what should be done.
If you have developed for a long enough period of time, you may have had an experience where you fixed something and a user started complaining.You tell the user that you fixed a problem - they tell you they liked it better the old way - who's right??
However, this behavior should be noted in the documentation for this xbasic command. Also, what would be helpful would be a list of known bugs and idiosynchrasies.

John