Beware builds past 2736-3523

[betty]

Re: Beware builds past 2736-3523

This sounds like the SAME issue that I've had with child records - attempting to renumber line items using the code by Dr. Wayne.

The other thing that I've found is that I don't have the issue with Alphasports - but I do have the issue with existing databases that I had previously created as well as new databases created in v10.

I have uninstalled and reinstalled Alpha and made sure that I have the latest updates. Unfortunately, I also had this issue with 2736-3523.

[betty]

Re: Beware builds past 2736-3523

Yes. That's exactly it. I uninstalled and went back to build 2736-3523. No more issues with the renumbering of child records - and when I delete a child record it deletes only the selected child record (it was also deleting all child records on a seemingly random basis).

Not sure why I did not have the issue with alphasports.

[martinwcole]

Re: Beware builds past 2736-3523

Here is my rule of thumb regarding new builds: If your current build works for you and your clients - DO NOT UPDATE!!! - unless of course there are new features you must have. Always save every build in a folder, so you can easily go back to a prior build.

And always thoroughly test a new build before deploying it to a client or your main app. And since this can be very very time consuming, why even get a new build unless absolutely necessary.

[Davidk]

Re: Beware builds past 2736-3523

Here's a sample database representing the problem.

One table, one form.

Open the form, change the type of payment or name or credit card number and then click on any other row. All the records will change according to the change you just made.

Now, click on any row and the 12th record will change to the values of the 1st record.

This occurs on every build after 2736-3523.

I've submitted a bug report.

[betty]

Re: Beware builds past 2736-3523

Or bug fixes

[sybs01]

Re: Beware builds past 2736-3523

Here's a sample database representing the problem.

One table, one form.

Open the form, change the type of payment or name or credit card number and then click on any other row. All the records will change according to the change you just made.

Now, click on any row and the 12th record will change to the values of the 1st record.

This occurs on every build after 2736-3523.

I've submitted a bug report.

Hi David,

I noted this same behavior in an Invoicing system I "built" using AlphaSports as a loose model. In my case, the last child "invoice_item" Description would change to match the 1st one, which was being pulled from the Product Description. I finally tired of pulling my hair out and added the Description field to the Invoice_item table and updated it along with price - it went away (I know, not a good normalization practice, but when time is of the essence....)

The difference from your problem was, it worked great in the development edition and the error only occurred in the run-time version. That was using the build associated with the original V10 download from late Nov, 2562-3504 (I'm assuming the "build" number we're talking about is derived from the build and add in number combined?).

I downloaded the run-time about a month or so after the development tool, (2649-3513 - but I'm unsure if the Dev and Run-time tools have any symmetry with regard to build numbers) so I wonder if perhaps whatever causes this was introduced in the time frame between those versions.

------------------------------------------------------------------------------------------------

I'm now experiencing a different issue with a Javascript error with the "Auto-Suggest List" look up feature. I found no similar posts regarding it, nor any responses to my post about it, so submitted a bug report.

The response I got was that I'm using a "very old" build (from Nov?) and the answer, of course, is to install the latest build, 2787-3538. The implication was that no fix resolutions for old builds would be forthcoming. I get the logic of this; maintaining and patching dozens of build versions would be hellish.

But, I have to say, I've read numerous posts like this one; i.e. applying patches has serious regression implications, risking the situation where that which once worked no longer works. The "chicken and the egg" quandary is unsettling. Do I install the patch in hopes of fixing the issue I'm having but risk breaking things that currently work, or eschew the patch so as to maintain stability?

I've learned to be risk-averse over the years and tend to lean towards Martin's philosophy of "if it ain't broke, don't fix it." Overall, we are reminded that updating to new builds is not a trifle and extensive regression testing is the only prudent course.

BTW - the problem persists with the new build.

[jkletrovets]

Re: Beware builds past 2736-3523

David

Attached is a quick rework with a stripped down form I made for you that works. I am only messing with the name field in my form...but change the name of any row and they will all be updated. The erroneous behavior you are seeing is not present in the new form I made in the zip.

I moved your code from the Canrowchange to the Onsave event. I made a UDF to run the code (easier to maintain imo).

In your form, the code you had attached ran everytime the user changed rows...even if they did not make a change.

Also, I noticed in your example you had an index with a comma in the index name. I would avoid that practice if possible as those types of things always come back to bite. Perhaps an underscore when you need to do that type of thing. I also added a unique ID field (UID) which is a meaningless index key but it is a great idea for app maintenance as it lets you absolutley identify each record in table. In this case I use it to absolutely set the sort order of the rows.

Hope this might help you some....

Regards,

Jeff

[Davidk]

Re: Beware builds past 2736-3523

Thank you so much Jeff... I'll have a look... very much appreciated. I didn't know about the comma in the index... I don't remember specifically adding any indexing yet.

Had a look now... I'll put this into my system... thanks. I'm so new to A5 I tend to stick with something that seems to work and not look much further. I like the UID stuff too... thanks Jeff.

[csda1]

Re: Beware builds past 2736-3523

Hi David,

Just some comments in general.

As Martin said, if it ain't broke, don't fix it, not at least until there is something driving you forward. On the other hand, you should be testing apps with newer versions as they come out, just hold off deploying them until well tested and/or needed.

There are many aspects of Alpha Five that are used in many ways that are never intended. The more you can stay on the straight and narrow, the less trouble you will have with patch releases and new versions. I myself, seldom see changes that affect operation between versions.

However, since my Alpha Five addins and utilities sometimes use Alpha beyond what is intended, I often do find myself in uncharted waters. Minute differences for them occasionally do crop up, most easily fixed because my code is highly "functionalized". As Jeff related, "I made a UDF to run the code (easier to maintain imo)", well, it's not "imo", it's a fact! And there are many other advantages as well. See my Function tips here.

As for naming any objects(not display values), table,s indexes, files, etc in Alpha Five, keep fieldnames and index names in DBF files 10 and under in length, and there should never be any special characters or spaces except for underscore. See Cal's Alpha Five naming tips here.

Many of the problems people report as bugs, are because they have used a syntax, naming conventions, idiosyncracy of A5, etc, that happen to work in a particular version or patch release, but don't in some other. While ideally you'd like to be have full flexibility doing anything, using any program has rules (of course not always documented!), and when you create something, you need to follow those rules as best as possible, because, that is the rules that the program is being created to, and anything outside that is fair game for change.

I use the "opportunity" of failure of a new release as a chance to bulletproof an application. My code works from A5v6 all the way through A5v10, with relatively little version-specific code. In fact, in most cases, it doesn't even care which version, it just tests whether a built-in feature is present, or works, and uses an alternative when not.

And of course, if you really do have a bug, it's always good to confirm it on more than 1 computer (or post an example for others to test) and to submit a bug report with the simplest example possible, and exact details of how to reproduce it.

Also, with my utilities and addons, there is a Diag Info button on the Help displays (which works whether licensed or not) that creates a very complete list of the Alpha Five and Windows environment you are running in.

[mastermind315]

Re: Beware builds past 2736-3523

Please check that last build, it is full of bugs... a lot of odd things still happening. Can't get values from calculated fields, the EXIT button for the reports are not working. When aligning fields on the report using the right click over the ruler it releases the selection and automatically does a new selection, very frustrating! Those are the ones I remember right now, I'll keep you informed.

[MikeC]

Re: Beware builds past 2736-3523

Elliot,
Does restarting Alpha and/or rebooting your Computer help at all?? Sure sounds like a hardware issue to me as when I have had similar issues it was due to that.

Also, when explaining an issue, be much more specific. That is, "not working","can't get...", and similar does not tell us much. Also context is of major importance---WHERE is the problem happening....only on a report, a form, a browse, an operation,...........all????

To say something is "full of bugs" is way too much of a generalization to even warrant anyone to consider if what you say has validity or not....almost sounds like venting!! :)

But don't get me wrong.....all input is great to try to have as many issues brought to Alpha's attention as we can----but know also that just by saying it here on the messageboard does not mean that Alpha sees it!

Just a few FYIs really---I did not mean to single you out Elliot.

[mastermind315]

Re: Beware builds past 2736-3523

I restarted the computer, I uninstalled Alpha 5 from one computer and installed it in another one, but it still doing the same wrong things... I'm designing a very simple report about the transactions of some clients. There are like 1,200 clients and a transactions history for about 3 years. The results are ok on the detail section. I put a summary field on the footer section of that particular group of transactions (for every year) and that result is not showing up. When I try to exit the preview via EXIT button it does nothing, I have to click the X on the upper right. I also posted another thread talking about the ascii codes. Alpha change the name of the fields if I use some ascii code (I design applications in Spanish and some letters are done as special character using the ALT + Code i.e �,�,�,�,�,�,�) if I use those characters for the LABEL FIELDS Alpha generates an error on that label. An example is: Direcci�n (which means Address) as soon as I change to the preview window for that form Alpha change the label for something like Direc????????n. I have to rename it like 3 or 4 times and then it stays correct. I also bought the Alpha Five Made Easy book by Susan and reading some parts she mention that "sometimes Alpha forget to save, or do something" isn't that a bug? The other frustrating part is when try to align the fields in a form using the right click over the ruler after doing a selection, that right click releases the selection and selects what is across the vertical (if you right click on the horizontal ruler) or the horizontal line (if you right click on the vertical ruler) on that part of the ruler making impossible to align what was selected the first time.

[MikeC]

Re: Beware builds past 2736-3523

Elliot,
Just to narrow it down a bit....and for sure not saying it should not work as you are trying....but do the same issues occur when NOT using the special characters--especially the exiting as it sounds a bit like Alpha is having a hard time either rendering or understanding something and is hanging up a bit .....

[mastermind315]

Re: Beware builds past 2736-3523

The special characters is one separate issue... and it only happens when using them. That is not supposed to happen, that's only a label, not a field that stores data which I know it could lead me to a problem soon or after. All the fields on the tables are without special characters.

[csda1]

Re: Beware builds past 2736-3523

Hi Eliot,

Let's look at the important aspects of what you stated.

I put a summary field on the footer section of that particular group of transactions (for every year) and that result is not showing up.

Is that a report, form or what? Are you trying to get a display on a form, or when printing out? What was your expression for the summary field? Summaries show up in my reports.

When I try to exit the preview via EXIT button it does nothing, I have to click the X on the upper right.

What type of layout are you previewing?

I also posted another thread talking about the ascii codes. Alpha change the name of the fields if I use some ascii code (I design applications in Spanish and some letters are done as special character using the ALT + Code i.e �,�,�,�,�,�,�) if I use those characters for the LABEL FIELDS Alpha generates an error on that label. An example is: Direcci�n (which means Address) as soon as I change to the preview window for that form Alpha change the label for something like Direc????????n. I have to rename it like 3 or 4 times and then it stays correct.

Having to do it 3 or 4 times, is a possible indication that Alpha didn't like it the 1st time. You may be making it worse by repeating to do it, and somehow it seems to eventually take it.

As I stated before,

As for naming any objects(not display values), table,s indexes, files, etc in Alpha Five, keep fieldnames and index names in DBF files 10 and under in length, and there should never be any special characters or spaces except for underscore. See Cal's Alpha Five naming tips here.

I'll add to that no characters over Ascii 126 or below Ascii 33 as well. The DBF file format was never designed for international languages, and thus I would never predict how it would handle other values outside the "normal" range for any program. I'm am only talking about object (label) names, and not the data itself or other displayable text (e.g. Help strings or field prompts). Unfortunately, you will have to deal with english characters for objects, and that is the safest route IMHO. This applies to the web server side as well, although many of the labels are really just data, and it may allow you to "get away with it".

I also bought the Alpha Five Made Easy book by Susan and reading some parts she mention that "sometimes Alpha forget to save, or do something" isn't that a bug?

She may have said that in her book, but I don't agree with what Susan said. I save 1000's of time each day all kind of development objects as well as data records, and have never, repeat, NEVER seen that. If that was really true, every developer would be clamoring Alpha for a fix. It may be, however a qualified statement, but I don't have the context.

But the real question is, did you experience a saving issue?

The other frustrating part is when try to align the fields in a form using the right click over the ruler after doing a selection, that right click releases the selection and selects what is across the vertical (if you right click on the horizontal ruler) or the horizontal line (if you right click on the vertical ruler) on that part of the ruler making impossible to align what was selected the first time.

Sounds like an annoyance, not a bug. If you have a problem with the UI (User Interface) in design mode, suggest something to Alpha via the Wishlist section of the message board.

My best guess is that many of your issues may be the use of high ascii codes where Alpha does not really permit them to be.