Novell Server - Records Crossover

[NancyL]

Re: Novell Server - Records Crossover

Ok, we're going to try it on the front.

[NancyL]

Re: Novell Server - Records Crossover

It doesn't work.
Two of us started orders and we both started off with the same order #. By the time the other user is finished with the header and enters in the parts region, they are showing on my screen. I knew exactly what parts she was entering.

When we enter an order we follow each field in the header and then go into the region. When I enter the region, her parts disappear.

We've read Cal's article and I guess this is an issue that they are working on. Working like this is not acceptable when your dealing with 20 or more users who are entering orders at the same time.

Thanks for you help and please let us know if you have any other advice. We'll take all we can get!

[Tom Cone Jr]

Re: Novell Server - Records Crossover

When we enter an order we follow each field in the header and then go into the region. When I enter the region, her parts disappear.

I would expect this behavior if your "header" record is in the "parent" table of the set supporting your form. And your "region" fields are in linked child table records.

It's not clear from your post how you're supplying the order id number when the "header" record begins, I assume it's being changed when you save the header record because the other workstations' data disappears from your display. Is my assumption correct?

In set based forms, when focus leaves the parent table fields, and enters an embedded browse displaying linked child table records, the form will automtically save the parent table record. Assuming your "header" record is the "parent" then this is working as designed. As others have indicated the best solution I've found here is to begin the new parent table record, stuff the order id number into its field, and then commit the new parent table record to disk. User then finishes the record in CHANGE mode rather than in ENTER mode.

[NancyL]

Re: Novell Server - Records Crossover

The order ID # is sytem generated. Your right that the order #'s are the same until one user saves it. To clarify the order # and the record (page #) are different.

To have to start the order, then save it and then change it is not acceptable. But we've come to the conclusion that it doesn't matter if 10 people start a record with the same order # as long as it saves different order #'s and it does. In fact after 13 years of using Alpha 4 we just realized that it works that way also.

Our biggest hurdle right now is trying to figure out how to fix the problem of the regions crossing. Imagine that mess with 20 people entering orders with the parts regions crossing.

This never happened with Alpha 4 but of course that's DOS.

[Tom Cone Jr]

Re: Novell Server - Records Crossover

Our biggest hurdle right now is trying to figure out how to fix the problem of the regions crossing. Imagine that mess with 20 people entering orders with the parts regions crossing.

To have to start the order, then save it and then change it is not acceptable.

If immediately saving the order header solves the "biggest hurdle" what's the big deal? If the user wants to cancel the order use a cancel button to delete the incomplete (but already saved) record. I am having trouble understanding why this is such a sticking point when it will (or could) be transparent to the user? They start a record by pushing a button. The button script begins the new record, grabs the next order number, saves the order record, and then the form opens for user edits.

[NancyL]

Re: Novell Server - Records Crossover

The order # isn't an issue now. We're just going to let the system save the order when the user hits the save record button, whatever order # it gives them will be it. I don't want the user to have the ability to cancel or delete order. Believe me with this many users that can cause a mess.

The problem is when user 1 is entering an order at the same time as user 2, and user 1 enters the parts region before user 2, user 2 can see all the parts that user 1 is entering. It can be very confusing for the users.

So your entering an order and you can see what parts Joe is entering on his order. It just doesn't make sense.

[Tom Cone Jr]

Re: Novell Server - Records Crossover

Nancy, how are you arranging for the order number to be filled in automatically? Are you using the autoincrement field rule or a custom script? It sounds as though you are using the field rule. If so, maybe you should consider using a custom script that runs on the 'Save' button, being careful to block edits to the details (child table) until that button has been pressed. In the context of your app what is a "region" and what is an "item"? Is "region" in the parent table of your set, or in a child? Is "item" in the parent table or in a child?

Later...
An easy way to get past your hurdle may be to simply hide the item browse and its supporting buttons when a new parent table record is begun. Your Save parent table record script could then assign a unique order number, and "show" the hidden objects for the user.

[NancyL]

Re: Novell Server - Records Crossover

Answering your first part, the order no is incremented automatically and is read only. (field rule)
The region is an embedded browse.

As for your later......I'll get back to you.
Thank you!

[sparkey]

Re: Novell Server - Records Crossover

While everyone is focusing on Alpha, has anyone checked what version of Novell and what type of file/record locking is being used as well what Novell Client is being used on each windows workstation ?

Past experience has shown me that bad things happen when MS's novell client is used along with Novell's client software on another terminal.

Also, there are different file locking settings for a Novell server as well as commit and cache settings that are available on each client as well......

Another thought. When entering data, before saving, is it caching locally or is it caching in a temp file on the Novell server ?


Some info regarding OES1 and Opportunistic Locking
http://www.novell.com/documentation/...a/btpfr3m.html

[manny]

Re: Novell Server - Records Crossover

Alpha Five Version (Registered): 9
Build: 1847 (THIS IS NOT AN UP-TO-DATE VERSION OF Alpha Five)
Addins: 3216 (THIS IS NOT AN UP-TO-DATE VERSION OF ADDINS)

Operating System: Microsoft Windows XP Professional Service Pack 3

Bug Description: When 2 or more users are entering a new record in a set while in the parent table, each can see the child records for the other in the set. When the user moves to the child table and enter a new record for the child table, the information previously seen disappears. And the record (parent and child tables) is saved correctly as intended.

Manny

[jkletrovets]

Re: Novell Server - Records Crossover

Welcome Manny.

Did you submit your bug report to Alpha (not this message board) as well? Also, this type of bug report will not likely garner much attention from Alpha - if you have a reproducible bug then you should try to include the app with your bug report.

That being said....I don't perceive there to be bug here. I think there is some other issue going on on your end. There are MANY people on this board who have multiuser applications with one to many relationships.

If I get a chance later today...I will try to make you a sample of a network ready app with a one to many schema.

Regards,

Jeff

[NancyL]

Re: Novell Server - Records Crossover

Your all missing the point!!!!!!!!!!!!!!
Manny is my programmer and I'm learning this as I go along.

MY POINT!
USER 1 AND USER 2 ARE ENTERING ORDERS AT THE SAME TIME.
FORGET THAT THE ORDER NUMBERS ARE THE SAME AT THIS POINT.

USER 1 COMPLETES THE HEADER PORTION OF THE RECORD AND NEEDS TO ENTER THE PARTS IN THE REGION (EMBEDDED BROWSE).

USER 2 IS STILL WORKING ON THE HEADER HOWEVER SHE CAN NOW SEE USER 1 PARTS THAT SHE'S ENTERING IN THE CHILD TABLE OF HER ORDER.

COME ON PEOPLE!!!! WITH 20 USERS ENTERING ORDERS AT THE SAME TIME THEY WILL ALL SEE WHAT EACH OTHER IS ORDERING? THAT'S NOT ACCEPTABLE.

WHEN YOU ENTER THE REGION THE PARTS DO DISAPPEAR BUT THIS WILL BE MUCH TOO CONFUSING FOR USERS.

[jkletrovets]

Re: Novell Server - Records Crossover

Your all missing the point!!!!!!!!!!!!!!

I don't think so. I understand your frustration but perhaps not yelling at someone trying to help you might be a better approach.

Manny is my programmer and I'm learning this as I go along.

I got that Nancy!!!!!!

I fully understand what you are seeing as well. I (and the others above) are trying to tell you that it is probably more a function of your programming / implementation that is causing your problem versus the actual software itself. Alpha could not exist if it could not handle this scenario. As I mentioned, there are many people on this board who are doing the same thing as you in a networked environment.

It looks like I might have some free time in a couple hours and I will try to put together a sample for you if you would like?

Jeff

[Peter.Greulich]

Re: Novell Server - Records Crossover

Your all missing the point!!!!!!!!!!!!!!
Manny is my programmer and I'm learning this as I go along.

MY POINT!
....

Ouch!

COME ON PEOPLE!!!! WITH 20 USERS ENTERING ORDERS AT THE SAME TIME THEY WILL ALL SEE WHAT EACH OTHER IS ORDERING? THAT'S NOT ACCEPTABLE.

WHEN YOU ENTER THE REGION THE PARTS DO DISAPPEAR BUT THIS WILL BE MUCH TOO CONFUSING FOR USERS.

Agreed. And it does sound like a bug to me, but what do I know?

However (I know you don't want to hear this), the work around is, as stated by Tom and others, to save the header first, thus locking in the unique linking ID. You would do this PROGRAMMATICALLY! This save operation would be TRANSPARENT to the end user.

Capice?

[Tom Cone Jr]

Re: Novell Server - Records Crossover

Nancy, I think what you're seeing is happening because the order number generated by the autoincrement field rule is the same on both workstations until both workstations save their header (parent table) record. The field rule computes the next autoincrement field value twice. Once when the new header record is begun. And again when the header record is saved. If two workstations begin new records but save neither of them, they'll have the same order number, at least temporarily.

In your application you need to develop a different way of assigning the next order number, as others have suggested previously in this thread. If you have to use the field rule then I recommend, again, that you arrange to immediately save the header record and let the user work in change mode. You have said, repeatedly, that that is not acceptable. So, now you have to "roll your own" code to assign the next order number. Sample scripts that do exactly this have already been given to you in this thread, but seem to have been ignored. Very puzzling. -- tom