• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Programming Help

jdewannab

Active Member
List,
I have a scenario that I need some input on!

I have a form created for Advance pricing where you enter in the Price Adjustment Name and Customer Number and also a Item number.
When you enter in the item number it will load the grid with items greater or equal to the item number on the form control with the same G/L Class.

Problem is this!
They select the items they want added by placing a 'Y' in a designated field. Is there a way I can do a sort on this field before reading grid records.

Example:
They enter in item 123

It pull the following data in the grid.
Item Number 456
Item Number 789

Say I Place a Y beside 789. When I hit the update button, I want all 'Y' to pull to the top so that I can read all grid rows until 'Y' are done and then stop....

Please help.
jdewannabe
 

tom_brown

Active Member
Why do you want the 'Y' values to pull to the top? Can you not just read
all rows in the grid and just process those which have a 'Y' in the field?

Perhaps these have not been loaded into the grid yet which would be a
problem, but you could just take the 'disable page at a time processing'
form option to sort this problem out - assuming this does not give you
performance problems.

Hope I was understanding the problem correctly.

Tom Brown
 

tpw_nz

Active Member
Wannabe,

I can think of a few things you can do to achieve this.

1. If the grid column that the "Y" maps to a business view column you would be able to use the system event "Set Sequencing" to sort your grid by the update column. The problem with this solution is you would first need to push "OK" to update your "Y"'s to the underlying table.

2. You could loop though all grid rows using "Get Max Grid Rows" and "Get Grid Row" and hide any rows that aren't "Y". Maybe you could put this code behind a check box to toggle between hiding and showing non "Y" rows?

3. Nasty, but what you wanted. Again using the "Get Max Grid Rows" and "Get Grid Row" you could scan through all the grid rows to find the "Y" ones. Then use "Insert Grid Buffer Row" to add the row to top of the grid, finally use "Delete Grid Row" on the current row so it only appears at the top of the grid. If you want to maintain any existing sort sequence you'll have to increment a counter everytime you insert a row and use the counter as the new row number.

Do you really need all the "Y" records at the top? If not you could just go through all the grid records using the method described above and do what you want when your find your "Y" records.


Hope of of these works for you.
 

jdewannab

Active Member
Thanks for everyones post.

I have thought about reading all grid rows and only processing the 'Y' records, but it would take a long time to read through all the records (Could be up to 1000 or more records just to process 5 Y records). This is the reason I wanted to pull the Y's to the top, so I could only process all 'Y's

The field that the Y populates does not reside in the business function, which means set sequencing will not work.

When they enter a Item number in the FC item Number it should do the following:
a. I will populate the grid with all items greater than or equal to item entered with same GL/CLass.

B. They then click the items they need and a dd field is populated with a 'Y'.

c. THey hit ok to insert the Y records in the schedule.

Any other suggestions on how to do this would be great.
Thanks
 

tpw_nz

Active Member
Wannab,

How about everytime a row is selected add a record to a new cache/worktable. Then the "OK" button could use the information stored in the cache/worktable to decide what to update.
 

Zoltan_Gyimesi

Legendary Poster
Hi Jimmy,

Would you be please, answer some questions:

1.) What is type of your form (e.g. Headerless Detail)?
2.) What kind of business view is behind the form? Is it a "dummy" one?
3.) Do you "Suppress Find" and populate the grid programatically? 3.a.) Which ER resides your populater code in?
4.) Do you suppress all DB actions (e.g. Add, Delete, etc.) on your form?
5.) Which ER resides your Y processor code in?
6.) Do you leave the form after they hit the OK and you processed all Y records?

If the answer is YES for 6 then why do you suppose that there is any method that could be faster than processing the Y record only on the OK button like:
If grd_SelectionFlag is equal to 'Y'
__F55xxyyy.Insert
Endif

How long time to process 5 Y from 1000 at your site?
Have you compared the process time for 5 of 5 and 5 of 1000 situations? Please, let us know the results if you have done. Thanks.

On the other hand, Trevor's great suggestions could work, but I suppose, you won't spare processing time using them.


Regards,
Zoltán
P.S.: Please, next time attach your system configuration informations too. Thanks.


B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
 

tom_brown

Active Member
If you are worried about the performance of reading a thousand records, then
you could create a workfile which holds the keys to the records which appear
in the grid.

Clear this workfile when the program starts, when the user selects a
line(changes the field to 'Y'), write the key to that line to a work file(if
they change it back to not be a Y you will have to delete the work file
record. Then when they leave the program, use the workfile to refer to the
reocrds which have been slected - this should just comntain your 5 records
now and you should be able to process these into your 'schedule' quickly.

Hope this helps

tom brown
 

Zoltan_Gyimesi

Legendary Poster
Hi Trevor,

If the Cache/Worktable resides in the DB than it will cause extra processing time to manage them (Insert at selection, Delete at clearing the selectin and delete all when exit).
Also it could be a problem when more than one execution of the applications happens in the same time. Further remained undeleted junk records also could cause problems (solution, delete all when enter the application).

If it resides in a RAM cache then it needs a lot of extra programing and I am not sure that it will have a acceptable performance benefits.

Regads,
Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
 

tpw_nz

Active Member
Zoltan,

The reason I suggested either cache or a worktable is some people feel more comfortable using worktables.

If a worktable was going to be used I would suggest using a unique job number a part of the primary key and removing all records for that unique number when the application closes.

I wouldn't have expected the time to insert or delete a single row to affect the performance of an application too badly.



Regards
 

Zoltan_Gyimesi

Legendary Poster
Hi Trevor,

There was no problem with your suggestion.
I also prefer using work table(s) in some situations.
We also use unique next number in the index to separate the records of concurrent runnings. We place always this field as first field of the index. As you very well know, it has an other advantage at deletions, namely we can use a single partiel key delete statement instead of a "classic OneWorld" Select/Fetchnext/While loop.
We delete the work table records (filterd by the unique number) as well at the beginning as at the ending of the process. The deletion at the begining prevents the faulty results caused by possibly existing undeleted junk records. Using the next number, it isn't a real danger, but you know, the best to be always on the safe side.

Let me an other note. If the work table has more than one index then very good habit to include the next number field as the first field into all indicies.

My only doubt about using database work table in Jimmy's situation was that grid processing works in memory, so it should be fast.

Regards,
Zoltán

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
 

Zoltan_Gyimesi

Legendary Poster
Hi Jimmy,

Here are other two cents.

What about to enable the Multiple Select on the grid and set the Repeat for Grid event option for your insertation logic instead of using the selection field in the grid.
You can place your logic as well on the Add standard exit as on a custom form exit as on a custom push button. You can also consider to remove the processed rows from the grid, enabling further selections and insertations for the user. It can make flexibility for the user, making the insertations one by one, group by group, etc as she/he likes.

If you want to exit the form after your insertation, then place your logic onto a hidden push button. Start the process on any "NON Repeat for Grid" Hyper Control event, calling your hidden button after that calling the Close/Cancel.

OK, I know, this solution has a disadvantage when the grid contains several records. If the user miss once the multiple selection key or mouse combination then the previous selections will be cleared.

Please, let us know, could it work for you. Thanks.

Zoltán
P.S.: You haven't answered my previous questions in one of my previous post on this thread. I would appreciate your answers.

B7332 SP11, ESU 4116422, Intel NT4, SQL 7 SP1
(working with B7321, B7331, XE too)
 
Top