RE: [development-axapta] Bad response time on the CUSTINVOICEJOUR form
Snap!!! Same probem here We have the same kind of number of records in the tables (FYI we have about 5 diff AX companies...do you have multi companies, not sure this has anything to do with the problem?) Also we found users who killed there AX session (thinking it was not responding) it actaully left the process in the SQL and it would not stop and took 100%!!! Look in your event viewer for things like AOS saying SPID xxx should be killed (i.e. AOS cannot kill it and you have to go into SQL yourself to do) We seemed to have fixed (just like 5 mins ago) for now but not sure, these are the steps we did for your info: 1) We added an index with invoicedate to custinvoicejour 2) Opened the form again and this time data appeared fine 3) We deleted the index and still the form is fine (this might be SQL caching of some kind I am not sure) Maybe you can first just test a compile of the form and then a full compile Still problem: Check in SQL do indexes exist on this table? (wondering if somehow the AOT indexes did not get to SQL) Do a sync from AOT for this table If these do not work then try creating an index on this table Anyone else having this problem? We thought it might be a AX system file corruption as we had some server problems a while back but it seems maybe it is more of a Standard AX problem since someone else has the problem Also I suggest you try putting the SQL statement in the SQL profiler to see what query path the SQL plans to use (maybe before you try any of the fixes) Looking forward to hearing from you Thanks James _ From: development-axapta@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of pkpeterson652 Sent: Wednesday, January 09, 2008 8:32 PM To: development-axapta@yahoogroups.com Subject: [development-axapta] Bad response time on the CUSTINVOICEJOUR form I have a response time problem with the CUSTINVOICEJOUR form. Accounts receivable \ Sales Orders \ Inquiries \ Invoices This form only has some minor modifications to it and when the mods are removed the same results are given. We are running Dynamics AX 4.0 at SP1, SQL Server 2005, and one AOS. The first time this option is selected it takes anywhere from 1 1/2 to 2 1/2 minutes to come up. Once the form has been opened up this form will come up in 1 to 2 seconds. I understand this because the necessary infomation is probably in the cache for the subsequent queries. I have run SQL trace and have isolated the offending query. I have taken the SQL statement shown in the SQL Trace log into the Database Engine tuning advisor, built and updated the recommended Statistics and built the recommend indexes. There are 166,506 records in the CUSINVOICEJOUR table across all companies and 108,388 records in the CUSTINOICESALESLINK table accross all companies. Any suggestions of what I should look at next? SQL Statement is as follows: SELECT A.CUSTGROUP,A.REFNUM,A.SALESID,A.ORDERACCOUNT,A.INVOICEACCOUNT, A.INVOICEDATE,A.DUEDATE,A.CASHDISC,A.CASHDISCDATE,A.QTY,A.VOLUME, A.WEIGHT,A.SUMLINEDISC,A.SALESBALANCE,A.ENDDISC,A.INVOICEAMOUNT, A.CURRENCYCODE,A.EXCHRATE,A.SALESADMINISTRATOR,A.INVOICEID,A.LEDGERVOU CHER,A.UPDATED,A.DIMENSION,A.DIMENSION2_,A.DIMENSION3_, A.ONACCOUNTAMOUNT,A.TAXPRINTONINVOICE,A.LISTCODE,A.DEL_PRINTED, A.DOCUMENTNUM,A.DOCUMENTDATE,A.INTRASTATDISPATCH,A.DELIVERYNAME, A.DELIVERYADDRESS,A.PURCHASEORDER,A.DLVTERM,A.DLVMODE,A.PAYMENT, A.CASHDISCCODE,A.INVOICEROUNDOFF,A.SUMMARKUP,A.COVSTATUS, A.RETURNITEMNUM,A.POSTINGPROFILE,A.BACKORDER,A.PREPAYMENT, A.DLVZIPCODE,A.DLVCOUNTY,A.DLVCOUNTRYREGIONID,A.DLVSTATE,A.TAXGROUP, A.TAXITEMGROUP,A.DEL_TAXSPECIFYTOTAL,A.TAXSPECIFYBYLINE, A.EINVOICELINESPECIFIC,A.DEL_CORRECTEDINVOICEID,A.ONETIMECUSTOMER, A.PAYMENTSCHED,A.SUMTAX,A.SALESTYPE,A.EINVOICEACCOUNTCODE,A.PARMID,A.E USALESLIST,A.EXCHRATESECONDARY,A.TRIANGULATION,A.CUSTOMERREF, A.VATNUM,A.NUMBERSEQUENCEGROUP,A.LANGUAGEID,A.INCLTAX,A.LOG, A.PAYMDAYID,A.INVOICINGNAME,A.INVOICINGADDRESS,A.INVZIPCODE, A.INVCOUNTY,A.INVCOUNTRYREGIONID,A.INVSTATE,A.GIROTYPE, A.CONTACTPERSONID,A.SALESORIGINID,A.BILLOFLADINGID,A.INVENTLOCATIONID, A.FIXEDDUEDATE,A.DELIVERYCITY,A.DELIVERYSTREET,A.INVOICECITY, A.INVOICESTREET,A.PRINTORIGINALS,A.PRINTCOPIES,A.INVOICEAMOUNTMST, A.INVOICEROUNDOFFMST,A.SUMMARKUPMST,A.SUMLINEDISCMST,A.ENDDISCMST, A.SALESBALANCEMST,A.SUMTAXMST,A.DEL_REFDLVZIPCODE,A.DEL_REFINVZIPCODE, A.INTERCOMPANYCOMPANYID,A.INTERCOMPANYPURCHID,A.PROFORMA, A.MILCHECKNUM,A.MILPAYMENTMETHOD,A.MILPAYMENTAMOUNT,A.CREATEDDATE, A.CREATEDTIME,A.CREATEDBY,A.RECVERSION,A.RECID, B.INVOICEID,B.INVOICEDATE,B.SALESID,B.ORIGSALESID,B.INVOICEACCOUNT, B.ORDERACCOUNT,B.DELIVERYNAME,B.DELIVERYADDRESS,B.PARMID, B.INVOICINGADDRESS,B.INVOICINGNAME,B.PURCHASEORDER,B.CUSTOMERREF, B.RECVERSION,B.RECID,A.DEL_CORRECTIVEREASON FROM CUSTINVOICEJOUR A,CUSTINVOICESALESLINK B WHERE ((A.DATAAREAID='100') AND (A.REFNUM=0)) AND ((B.DATAAREAID='100') AND A.SALESID=B.SALESID) AND (A.INVOICEID=B.INVOICEID)) AND
FW: [development-axapta] Bad response time on the CUSTINVOICEJOUR form
Sorry if this already got through to the group...I realised i think i sent it with the wrong email the first time so it wont get through _ From: James Flavell [mailto:[EMAIL PROTECTED] Sent: Thursday, January 10, 2008 12:06 PM To: 'development-axapta@yahoogroups.com' Subject: RE: [development-axapta] Bad response time on the CUSTINVOICEJOUR form Snap!!! Same probem here We have the same kind of number of records in the tables (FYI we have about 5 diff AX companies...do you have multi companies, not sure this has anything to do with the problem?) Also we found users who killed there AX session (thinking it was not responding) it actaully left the process in the SQL and it would not stop and took 100%!!! Look in your event viewer for things like AOS saying SPID xxx should be killed (i.e. AOS cannot kill it and you have to go into SQL yourself to do) We seemed to have fixed (just like 5 mins ago) for now but not sure, these are the steps we did for your info: 1) We added an index with invoicedate to custinvoicejour 2) Opened the form again and this time data appeared fine 3) We deleted the index and still the form is fine (this might be SQL caching of some kind I am not sure) Maybe you can first just test a compile of the form and then a full compile Still problem: Check in SQL do indexes exist on this table? (wondering if somehow the AOT indexes did not get to SQL) Do a sync from AOT for this table If these do not work then try creating an index on this table Anyone else having this problem? We thought it might be a AX system file corruption as we had some server problems a while back but it seems maybe it is more of a Standard AX problem since someone else has the problem Also I suggest you try putting the SQL statement in the SQL profiler to see what query path the SQL plans to use (maybe before you try any of the fixes) Looking forward to hearing from you Thanks James _ From: development-axapta@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of pkpeterson652 Sent: Wednesday, January 09, 2008 8:32 PM To: development-axapta@yahoogroups.com Subject: [development-axapta] Bad response time on the CUSTINVOICEJOUR form I have a response time problem with the CUSTINVOICEJOUR form. Accounts receivable \ Sales Orders \ Inquiries \ Invoices This form only has some minor modifications to it and when the mods are removed the same results are given. We are running Dynamics AX 4.0 at SP1, SQL Server 2005, and one AOS. The first time this option is selected it takes anywhere from 1 1/2 to 2 1/2 minutes to come up. Once the form has been opened up this form will come up in 1 to 2 seconds. I understand this because the necessary infomation is probably in the cache for the subsequent queries. I have run SQL trace and have isolated the offending query. I have taken the SQL statement shown in the SQL Trace log into the Database Engine tuning advisor, built and updated the recommended Statistics and built the recommend indexes. There are 166,506 records in the CUSINVOICEJOUR table across all companies and 108,388 records in the CUSTINOICESALESLINK table accross all companies. Any suggestions of what I should look at next? SQL Statement is as follows: SELECT A.CUSTGROUP,A.REFNUM,A.SALESID,A.ORDERACCOUNT,A.INVOICEACCOUNT, A.INVOICEDATE,A.DUEDATE,A.CASHDISC,A.CASHDISCDATE,A.QTY,A.VOLUME, A.WEIGHT,A.SUMLINEDISC,A.SALESBALANCE,A.ENDDISC,A.INVOICEAMOUNT, A.CURRENCYCODE,A.EXCHRATE,A.SALESADMINISTRATOR,A.INVOICEID,A.LEDGERVOU CHER,A.UPDATED,A.DIMENSION,A.DIMENSION2_,A.DIMENSION3_, A.ONACCOUNTAMOUNT,A.TAXPRINTONINVOICE,A.LISTCODE,A.DEL_PRINTED, A.DOCUMENTNUM,A.DOCUMENTDATE,A.INTRASTATDISPATCH,A.DELIVERYNAME, A.DELIVERYADDRESS,A.PURCHASEORDER,A.DLVTERM,A.DLVMODE,A.PAYMENT, A.CASHDISCCODE,A.INVOICEROUNDOFF,A.SUMMARKUP,A.COVSTATUS, A.RETURNITEMNUM,A.POSTINGPROFILE,A.BACKORDER,A.PREPAYMENT, A.DLVZIPCODE,A.DLVCOUNTY,A.DLVCOUNTRYREGIONID,A.DLVSTATE,A.TAXGROUP, A.TAXITEMGROUP,A.DEL_TAXSPECIFYTOTAL,A.TAXSPECIFYBYLINE, A.EINVOICELINESPECIFIC,A.DEL_CORRECTEDINVOICEID,A.ONETIMECUSTOMER, A.PAYMENTSCHED,A.SUMTAX,A.SALESTYPE,A.EINVOICEACCOUNTCODE,A.PARMID,A.E USALESLIST,A.EXCHRATESECONDARY,A.TRIANGULATION,A.CUSTOMERREF, A.VATNUM,A.NUMBERSEQUENCEGROUP,A.LANGUAGEID,A.INCLTAX,A.LOG, A.PAYMDAYID,A.INVOICINGNAME,A.INVOICINGADDRESS,A.INVZIPCODE, A.INVCOUNTY,A.INVCOUNTRYREGIONID,A.INVSTATE,A.GIROTYPE, A.CONTACTPERSONID,A.SALESORIGINID,A.BILLOFLADINGID,A.INVENTLOCATIONID, A.FIXEDDUEDATE,A.DELIVERYCITY,A.DELIVERYSTREET,A.INVOICECITY, A.INVOICESTREET,A.PRINTORIGINALS,A.PRINTCOPIES,A.INVOICEAMOUNTMST, A.INVOICEROUNDOFFMST,A.SUMMARKUPMST,A.SUMLINEDISCMST,A.ENDDISCMST, A.SALESBALANCEMST,A.SUMTAXMST,A.DEL_REFDLVZIPCODE,A.DEL_REFINVZIPCODE, A.INTERCOMPANYCOMPANYID,A.INTERCOMPANYPURCHID,A.PROFORMA, A.MILCHECKNUM,A.MILPAYMENTMETHOD,A.MILPAYMENTAMOUNT,A.CREATEDDATE, A.CREATEDTIME,A.CREATEDBY,A.RECVERSION,A.RECID, B.INVOICEID,B.INVOICEDATE,B.SALESID,B.ORIGSALESID,B.INVOICEACCOUNT,
[development-axapta] Clsiter indexes yes or no?
Should be disable cluster indexes or not in Ax4.0? I know the pros and cons but my impression is for AX at least we should turn them of until someone in MS takes a good look and think slong and hard about which index is the best as a clsuter index. Anyone agree/disagree? Thanks James [Non-text portions of this message have been removed]
[development-axapta] Inventory dimension - help
Hi , I need to disable the some fields[SerialId,BatchId,ColorId,SizeId,PalletId] from the inventdimparmfixed form. Is this possible?. if possible how? Any suggestion is appreciable. thanks, SIva We Born to Win... - Looking for last minute shopping deals? Find them fast with Yahoo! Search. [Non-text portions of this message have been removed]
Re: [development-axapta] Re: Logo in SalesInvoice
Hi!:
Thanks Emanuela!.
I found what's happening.
We have the code that you sent but
in the method changeDesign the
Logo was disabled.
I put a comment in the line code
and thta's all (for blank paper).
:
//PageHeader Logo
switch(prePrintLevel)
{
case PrePrintLevel::BlankPaper :
if (!CustFormletterParameters::find().printInvoiceVATNum)
{
// #VisibleFalse(CompanyLogo)
#VisibleFalse(CompanyVATNum)
}
Emanuela [EMAIL PROTECTED] wrote:
--- In development-axapta@yahoogroups.com, jquinteroz
[EMAIL PROTECTED] wrote:
Hi!:
I need to insert a logo in SalesInvoice.
Do I need just insert the bmp file in
PageHeader:Logo or PageHeader:Invoice
section?.
Do I need to make some code for that?.
Regards.
You can add a field bitmap into design (page header) with a
displayMethod like this:
display Bitmap companyLogo()
{
return FormLetter::CompanyLogo();
}
-
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
[Non-text portions of this message have been removed]
