Maverick,

In response to your questions/points made

1. The only way to guarantee the recIDs will be in sequential order is
for you to be running the only process on the system at the time the
information is stored.  If someone inserts a record into another table
while your process is running, then you will no longer have a continuous
sequence for your table.  This includes you. 

2. ---

3. Without knowing more about what you are trying to do, I can not offer
further guidance.

4. Good, use where possible.

5. Should automatically return records in the order of the primary
index.

6. ---

7. ---

8. ---

9. I take it you are referring to the use of the skip* methods.  Have
you read the system documentation in Axapta on the skip* methods?  What
do you want to know?

10. ---

11. ---

12. ---

13. While you may not be able to provide the exact table structure being
used, you can indicate if the variables concerned use the same table
structure, or a different one, eg.
            Axxxxxx                  STable1, STable2;
            Bxxxxxx                  STable3, STable4, UpdateSTable;

14. ---

15. ---

16. ---




-----Original Message-----
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Maverick
Sent: Wednesday, 11 January 2006 10:26 PM
To: [email protected]
Subject: Re: [development-axapta] Performance Issue

Thanks All, Barry and Jacob,

I had seen all your points, and found it very useful. I have made some
points in them in bold and italic, please read it and reply.

This is What you have send, with edition-----


1. Do not use RecId as the index for the table.  Unless you were the
sole person populating the table, to my knowledge, there is no guarantee
that the RecId will be in the sequence you expect.  It is easy enough to
add a number sequence to a table to ensure the order you require.

This is a tool executed once at a time. So only one instance will be
running at a time. I had run my tool several time and found recid in
sequential manner, may  be it is because one instance can only run.


2. Check the indexes, and make sure you have an index for your Find.
Yes ,You are right and I had taken care of the indexes.

3. Do not update fields that make up part of the index (where possible).
I have found this slows execution.
Then what do you suggest "Order by" is better than if I want to sort the
records.


4. Make use of update_recordset where possible.
Yes on few of otherplaces I have used update_recordset.

5. I have found code runs slower when Index or Index Hints are added to
select statements.  Remove where possible.  If sequence order is
important then
      A) Use Index
      B) Use Order By
      C) Use primary index on the table definition.  (if your case, this
is likely to be the best option).
Yes, I had made it a primary key, so now what do u suggest whether I
have to use Index in select statements or It will automatically work in
the primary index format.

6. You seem to have unnecessary calls to .Clear().  Remove them.
Ya I know, that there are unnecessary  calls to clear()... So definitely
I will remove them.

7. Consider using joined select statements.
Right.


8. Minimise the amount of information transferred. Eg Modify the code

              select firstonly STable3 index RecIdx
              where STable3.RecId     >  STable1.RecId        &&
                    Stable3.TokenName == ")";

To (I have left the index statement in on purpose for this example)

              select firstonly RecId
              from   STable3 index RecIdx
              where STable3.RecId     >  STable1.RecId        &&
                    Stable3.TokenName == ")";                       
Right.

9. If update() has not been overloaded use update() instead of
doUpdate().  You never know what changes will be required in future.
You can always add the Skip* series of methods if required.
Please provide more info on this.

10. Before doing an update() you should check that the record exists.
Ie what happens when the code used in the example for point 8 returns no
records?  The check can be as simple as if (Stable3) { }.  You have done
this in a few places but not all.
you are right.

11. Personally, I would modify the code to use switch statements were
possible.  I find it easier to check the logic of the code.
I also prefer to use switch case.

12. Try and do the update only once.  If the situation occurs where only
one update is occurring, why continue with the rest of the code in the
loop.
Now I had converted the code in different modules means methods.

13. When you post code for people to examine, also include the
declaration / header statements.  This way we know if Stable1, Stable2,
Stable3, Stable4, UpdateSTable are actually defined as pointing to the
same table structure or not.  It was one of the pieces of information I
did ask to be provided.
I can not provide you the information, sorry for that.

14. Indexes on the tables are important.  How many do you have?  How are
they defined?  Incorrectly indexing, or having to many indexes can
adversely effect code performance, especially when doing inserts and
updates.  Indexes were one of the pieces of information I asked to be
provided.
I am in need of only one index and that I have created as a primary.

15. Modify your code to minimise the tts log that is generated.  Is it
your intension to lock the entire table for your own use while this
process is being done?  This can be done by creating a series of methods
and calling them where needed.  The methods can then have the necessary
tts log.  NOTE:  before changing your tts set-up, ask yourself, if the
code fails, do I need all the changes made to roll-back?  If No, then
modify your tts usage.
Now I had converted the code in different modules means methods.So locks
are for shorter duration.

16. Reread the comments by Jacob Hjelmer.  (Contained in the message
below).
I will take care of those things also.


Hope this helps.



Maverick, in your original email you stated

      "I have some code which is processing thousands of update on the
table. This process is doing all the updates on one table. Updates
consists of inserting new record and updation of a record."

And yet, the code you supplied does not do any insertion.  Was this
      1) An accident mistake.
      2) An indication that not all the code concerned was posted?


Yes dear Barry, there is a lot of other processes, but one of the method
doing updates is this. So I just wanted a help on this behalf. Sure I am
going to work on more things, since I have to do more optimization for
this tool. I wil be sharing all the info, if I found it useful for
optimizing code and database steps.

Maverick


[Non-text portions of this message have been removed]






Yahoo! Groups Links











SPONSORED LINKS
Computer part Programming languages Microsoft axapta
Support exchange


YAHOO! GROUPS LINKS




Reply via email to