Bug report

[dcorcoran]

I am very frustrated with the strange things my application is doing listed below in the bug report sent to Alpha this morning. I had sent another bug report on the 9th of May and never received a reply, anyway if anyone has experianced the same problem and coul help I would appreciate it.

I have already sent a bug report over a month ago concerning these issues and have not received a reply, I need urgent answers as my client is getting very frustrated.

I converted my old dos based program, which worked perfectly well and quick over the network, but he needed to use bar codes and other windows facilities, so we decided on Alpha Five which I have used for some years now but not with such a big client. The client is an importer of British foods to Spain has over 5.000 products and 30 supermarkets to supply from the warehouse on a daily basis.

I designed the database based on Alpha Sports invoice system. The first problem I ran into was that when more than one operator was entering invoices the invoice items from another operator were appearing on there screen. I was using Alpha�s sequential numbering system. I reported this problem on the board and was referred to Dr Peter Wayne article on learning Alpha and I am now using his method for sequential numbering of the invoices, this solved the original problem, but created another problem which is where the program is misbehaving. With Dr Wayne�s method if an operator went to enter a new invoice and then decided to cancel it then you have an invoice number skipped in the sequence. Then if you go and use the skipped number and are entering invoice items after you have gone to the next item the invoice header skips to the next invoice number and you end up entering items in the wrong invoice number, as you can imagine this causes all sorts of problems. Also this happens more on the network than on my machine as a single user.

Kind regards

David

[martinwcole]

RE: Bug report

I have this kind of scenario, but in my case it would be literally illegal to "delete" an order, so they can "cancel" an order (invoice) but it marks it as cancelled, and they cannot delete it.

I use a roll-your-own invoice number approach, where the invoice number is not even assigned until they save the parent, and displays as "TEMP" until they save the parent.

[Tom Cone Jr]

RE: Bug report

""Then if you go and use the skipped number ...""

In Dr. Wayne's system this not possible. You must have modified it to re-set the number if the user cancels an invoice in mid-stream. As Martin suggests, one solution here is to never re-use a number. Just leave the invoice header in the system and mark it cancelled by user, or some such. This is an approach I've used also, since I like to fetch the "next number" immediately, and then save the new invoice header record to disk immediately, also, even if it's not filled in completely. This seems to work better in multi-user networked cases. The users can never begin a record and then walk away from their workstations before it's saved. Instead, when the new record is started it's saved to disk immediately, with the correct invoice number. They then work in "change" mode to finish the order, and if they walk away it makes no difference to the integrity of the invoice numbering scheme. Do you see what I mean? -- tom

[russ Boehle]

RE: Bug report

Adding to the previous, regarding the items being saved to the wrong invoice number, this will not happen if you force the user to save the parent before entering child records. then you can save the invoice number to a variable and use this to put the invoice number on each line that is associated with the parent. This will prevent mismatches since the variable is stored locally so noone else can use it to create mismatched records.

Russ

[CALocklin]

RE: Bug report

I kinda hate to say this but I have to disagree with you Russ. If you were to change your statement to "this should not happen", then I'd agree.

I have an app that works perfectly on stand-alone systems but messes up occassionally on networks. I keep hoping to eventually find a problem in my routines but 10-12 concentrated searches over the past 6 months haven't found anything yet. (It would help if I could duplicate the problem but it only happens on networked systems and even then it is rare -- 0-4 times a week on a system where users are entering 125-200 orders a day.)

The issue only seems to occur when two or more users are entering data on a networked system. It seems to happen when both are entering new records in the 1:M child table BUT, like Tom, my app never allows the user to work in the Enter mode. They click to enter a new record and a new record is immediately created and saved via xbasic. This record is then opened for "entering" (in Change mode) the new data. At this point, everything seems ok and the data is correctly linked to the parent.

OCCASSIONALLY, when one of the users saves his child record after "entering" his data, the linking number in the parent record is changed!! It is incremented to the next number in sequence. (This is also a "roll-your-own" autoincrement.) The user knows it immediately because the system returns to the parent record and all the orders are missing. (The child record is entered via a separate form based only on the child table. The "parent" form is resynched and the user is returned to the "parent" form when the "child" form is closed.)

I have been over and over every script that seems to be anywhere close to affecting this (both when starting the child record and when saving it) and can't find a problem. I can't even find anything that should change the parent's linking field for any reason. (Of course, there are references to the field but nothing ever even has the parent record in change mode.) It seems that upgrading memory to 512 helped (one computer on one system was at 168) but it hasn't solved the problem.

This is happening on multiple networked systems but never happens on a stand-alone system.

I've even considered offering a $500 reward to anyone who can find my problem but this is a generic app and I'm not crazy about giving out code that has been through more than 2000 hours of development.

Cal Locklin
www.aimsdc.net

[Jerry Gray]

RE: Bug report

Cal,

I don't know if it is relevant but...

In my app the document ID is calculated in the field rules for the file. In a form, a button is clicked for approval and print. The script updates 3 fields, adds a record to another file and prints the document. Somewhere in the process, the document ID is changed.

Before ID: 112 -D-050611-12345678
After ID: -D-050611-12345678

The six character prefix is the department id for the employee in question. Prior to calculation, the department number is set in a global variable through a lookup.

The document ID isn't mentioned in the script. No key fields are updated with the approval so I'm concluding that it has to be something with the field rule.

There is a script that is called from the Record CanSave and/or Record CanDelete events in the field rules. It causes an Audit record to be written to an Audit file where it takes the existing document ID and uses it as the key for the document in the audit file.

I'm just starting my research on this anomoly. I'll try to remember to post my findings.

Jerry Gray

[dcorcoran]

RE: Bug report

"They click to enter a new record and a new record is immediately created and saved via xbasic. This record is then opened for "entering" (in Change mode) the new data."

I would appreciate if you could give me the xbasic code to do this and tell me where it is put. I think this could solve most of the problem.

Kind regards
David

[dcorcoran]

RE: Bug report

'Save record in current form at parent level.
topparent.commit()

'Change record in current form at parent level.
topparent.allow_change(.t.)

I tried putting the above code at the bottom of Dr Wayne's script in the "OnEnterRecord" and it does not work. I put it on a button and it works but I don't want to rely on the operator to do this so where do I put it?

Kind regards
David

[russ Boehle]

RE: Bug report

Yikes, I haven't run into this and hope I don't. Maybe some of the odd stuff will not happen when Alpha runs off of Mysql.
It certainly seems odd that a saved invoice number gets changed. Maybe I haven't run into it since we usually have only one person changing or adding records at a time (but not always). This is due to change soon so i hope I don't see this.

Russ

[martinwcole]

RE: Bug report

Cal, my bet is that if YOU can't find the error, it will take someone like Ira to help you.

That said, I've been thinking about your problem.

For my roll-your-own autoincrement field, a user pushes a button to 'enter a new record' - this sets in motion code in record events that opens a file and gets and increments a number, closes the file, and then sets the record's value for that field. And in my approach this supposedly can only occur from a request for a NEW record. The roll-your-own autoincrement script can only fire, logically, when a NEW record is created.

In version 5, I recently ran into a situation where at least one of several workstations was slow, and would mess things up. I resolved it by putting

sys_send_keys("{f5}")
xbasic_wait_for_idle()

at the top of the script.

I don't know if this will help in your case or not. I would suggest creating a log file with machinename, formname, timetoseconds, etc., and write to it from a fieldrules script in the table's onenterrecord and cansaverecord events to see if I could trace it that way. Also, I would set the current record's value to a global variable when adding a child, and compare it at the onactivate event and also write to the log when it varies along with the time.

If the parent is getting a "new" id, then something has to be tripping 'enter a new record.' If I understand correctly, the code to increment the next id only occurs when entering a new record, and if like mine fires from a fieldrules script. This logically HAS to be the problem.

I hope you resolve it, or else several others get it too, so Alpha will trace it.

I would be interested in seeing your autoincrement script as well as the event that triggers it.

[dcorcoran]

RE: Bug report

"then you can save the invoice number to a variable and use this to put the invoice number on each line that is associated with the parent."

Can you tell me the mechanics of how to do the above.

Thank you in anticipation.

Kind regards
david

[Lenny Forziati]

RE: Bug report

Custom code that you've found and implemented but does not fully meet your needs is NOT a bug.