Continuing the discussion of DWMX speedup opportunities from earlier today, I've learned something interesting. After looking at a sample from someone reporting sever delays, I observed something that definitely explain things for some people. She had reported that a very large file (approx 1000 lines) was taking a long time to load. But anyone opening such a file of HTML content would say it was no problem at all.
The thing is, this was a CF template and the code had several CFQUERY's in it, run conditionally so it's not about doing several at runtime, but still this causes issues for DWMX that one might not anticipate. It tries to load up the bindings tab with each CFQUERY to create what DWMX calls a recordset. It also loads up CFPARAM tags and FORM/CFFORM tags there as well, among other things.
So DWMX is clearly processing the page when it opens it, and with a dynamic page like CF it's going to be looking at the code to figure out things like this. (Indeed, she mentioned having inherited one code sample that had 36 queries in CFSWITCH/CFCASE statements!).
Many will want to point out that such code is itself a source of problems in its design (and she realizes that it's code that will benefit from redesign, especially in CFMX with components), but the bottom line is that there are code examples out there that will indeed suffer during opening in DWMX because of this issue. I didn't find any undue time spent while switching from one file to another, though.
I don't see any feature to get DWMX to no perform this preprocessing. If anyone knows of one, please do share. :-)
Tuesday, November 12, 2002
More Speedup Tips for DWMX
In my 10/16 entry, I pointed out one way to speed up DreamWeaver MX. I have a little more detail and a couple more ideas now.
I had mentioned how you could see Edit Site, then on the "Advanced" tab, in "Local Info" turn off "Refresh Local File List Automatically". I didn't point out that the same setting exists in the "Testing Server" field there as well. These will be a big help with respect to the speed of switching in and out of DWMX. This feature is intentional as it's trying to detect if while you were out of DWMX you were perhaps creating new files (such as when folks do indeed switch out to Studio/HomeSite). But if you don't make such file additions/deletions, or if mostly you're switching out to read email, etc, then this "auto refresh" is an expensive operation. Turn it off and much slowness will go away.
Similarly, the "Remote Info" section of the Advanced tab has a checkbox "automatically upload files to server on save", again to keep your remote machine in sync. Maybe you won't really want that feature enabled (and it will certainly slow down all saves). This feature is available in all the forms of remote access (ftp, local/network, RDS, SourceSafe and WebDAV).
Some have also suggested turning off Virus checking of the DWMX "Config" directory, though I've not experience that doing much good (but I may have gained so much with these other changes that it didn't add much).
I'd welcome anyone else's thoughts. This seems an important problem for so many that it would be useful to gather some ideas.
I had mentioned how you could see Edit Site, then on the "Advanced" tab, in "Local Info" turn off "Refresh Local File List Automatically". I didn't point out that the same setting exists in the "Testing Server" field there as well. These will be a big help with respect to the speed of switching in and out of DWMX. This feature is intentional as it's trying to detect if while you were out of DWMX you were perhaps creating new files (such as when folks do indeed switch out to Studio/HomeSite). But if you don't make such file additions/deletions, or if mostly you're switching out to read email, etc, then this "auto refresh" is an expensive operation. Turn it off and much slowness will go away.
Similarly, the "Remote Info" section of the Advanced tab has a checkbox "automatically upload files to server on save", again to keep your remote machine in sync. Maybe you won't really want that feature enabled (and it will certainly slow down all saves). This feature is available in all the forms of remote access (ftp, local/network, RDS, SourceSafe and WebDAV).
Some have also suggested turning off Virus checking of the DWMX "Config" directory, though I've not experience that doing much good (but I may have gained so much with these other changes that it didn't add much).
I'd welcome anyone else's thoughts. This seems an important problem for so many that it would be useful to gather some ideas.
Date processing with Access in CF
Some folks have had problems doing date processing within SQL against an Access database. (Let's not get into whether anyone should be choosing Access as a DB. For some low volume sites, it works adequately.)
Part of the date handling problem stems from the fact that Access may need help determining that what you're passing it is a date (versus a number). There are two ways to do this. You could use the CreateODBCDate() function to convert a date to a format that will be passed from CF to SQL as an ODBC Formatted date.
Another is to take advantage of the fact that Access can use pound signs around a date to indicate that the value is a date. Of course, those are the same pound signs that CF uses for variables, which can complicate things.
First, just know that one way to format a SQL statement WITHIN Access to process, for instance, records between two dates (leave CF out of the picture for a moment) would be to render it as:
SELECT StartDate FROM Employee WHERE StartDate between #01/01/97# and #01/01/98#
If you wanted to do that within a CFQUERY statement, then you'd need to escape those pound signs (double them) so that CF didn't think you were trying to refer to variables, as in:
<CFQUERY NAME="test" DATASOURCE="CompanyInfo">
SELECT StartDate FROM Employee WHERE StartDate between ##01/01/97## and ##01/01/98##
</CFQUERY>
Of course, you could also convert this to use the ODBCDateFormat function, as in:
<CFQUERY NAME="test" DATASOURCE="CompanyInfo">
SELECT StartDate FROM Employee WHERE StartDate between #ODBCDateFormat("01/01/97")# and #ODBCDateFormat("01/01/98")#
</CFQUERY>
Notice again that the use of this function doesn't require the use of escaped pound signs because the function creates the date in a format Access understands. But you'll usually have the date coming in as a variable. You could then easily change the ODBCDateFormat as in:
<cfset date="01/01/98">
<CFQUERY NAME="test" DATASOURCE="CompanyInfo">
SELECT StartDate FROM Employee WHERE StartDate between #ODBCDateFormat("01/01/97")# and #ODBCDateFormat(date)#
</CFQUERY>
But if you tried to use the Access form of passing pound-delimited dates, such as in the first two examples above, and you wanted to use a variable for one of them, you'd then need 3 pound signs around that (two for the escaped pound for Access and one for the pound needed to refer to the variable/function), as in:
<cfset date="01/01/98">
<CFQUERY NAME="test" DATASOURCE="CompanyInfo">
SELECT StartDate FROM Employee WHERE StartDate between ##01/01/97## and ###date###
</CFQUERY>
Finally, note that if you wanted to use the now() function in that last example for the date (which returns the current date AND time), or if your incoming "date" variable had minutes and seconds in it, you'd need to wrap it in a dateformat function before using the "pound sign" approach to date formatting in Access because that doesn't like anything but a date to be passed in, as in:.
<CFQUERY NAME="test" DATASOURCE="CompanyInfo">
SELECT StartDate FROM Employee WHERE StartDate between ##01/01/97## and ###dateformat(now())###
</CFQUERY>
Note, too, that I've not bothered with any date formatting "mask". In my testing, Access is happy with the default dateformat form of date layout.
So when should you use the pound sign approach? Well, really, it's more something that's needed within Access itself to be able to detect that a string of numbers (and dashes or slashes) are in fact representing a date. The thing is, with the ODBCDateFormat function (and CF's Now() returning a date in ODBCDateTime Format), it's perhaps not as important to use the pound-surrounded approach to dates in Access.
Part of the date handling problem stems from the fact that Access may need help determining that what you're passing it is a date (versus a number). There are two ways to do this. You could use the CreateODBCDate() function to convert a date to a format that will be passed from CF to SQL as an ODBC Formatted date.
Another is to take advantage of the fact that Access can use pound signs around a date to indicate that the value is a date. Of course, those are the same pound signs that CF uses for variables, which can complicate things.
First, just know that one way to format a SQL statement WITHIN Access to process, for instance, records between two dates (leave CF out of the picture for a moment) would be to render it as:
SELECT StartDate FROM Employee WHERE StartDate between #01/01/97# and #01/01/98#
If you wanted to do that within a CFQUERY statement, then you'd need to escape those pound signs (double them) so that CF didn't think you were trying to refer to variables, as in:
<CFQUERY NAME="test" DATASOURCE="CompanyInfo">
SELECT StartDate FROM Employee WHERE StartDate between ##01/01/97## and ##01/01/98##
</CFQUERY>
Of course, you could also convert this to use the ODBCDateFormat function, as in:
<CFQUERY NAME="test" DATASOURCE="CompanyInfo">
SELECT StartDate FROM Employee WHERE StartDate between #ODBCDateFormat("01/01/97")# and #ODBCDateFormat("01/01/98")#
</CFQUERY>
Notice again that the use of this function doesn't require the use of escaped pound signs because the function creates the date in a format Access understands. But you'll usually have the date coming in as a variable. You could then easily change the ODBCDateFormat as in:
<cfset date="01/01/98">
<CFQUERY NAME="test" DATASOURCE="CompanyInfo">
SELECT StartDate FROM Employee WHERE StartDate between #ODBCDateFormat("01/01/97")# and #ODBCDateFormat(date)#
</CFQUERY>
But if you tried to use the Access form of passing pound-delimited dates, such as in the first two examples above, and you wanted to use a variable for one of them, you'd then need 3 pound signs around that (two for the escaped pound for Access and one for the pound needed to refer to the variable/function), as in:
<cfset date="01/01/98">
<CFQUERY NAME="test" DATASOURCE="CompanyInfo">
SELECT StartDate FROM Employee WHERE StartDate between ##01/01/97## and ###date###
</CFQUERY>
Finally, note that if you wanted to use the now() function in that last example for the date (which returns the current date AND time), or if your incoming "date" variable had minutes and seconds in it, you'd need to wrap it in a dateformat function before using the "pound sign" approach to date formatting in Access because that doesn't like anything but a date to be passed in, as in:.
<CFQUERY NAME="test" DATASOURCE="CompanyInfo">
SELECT StartDate FROM Employee WHERE StartDate between ##01/01/97## and ###dateformat(now())###
</CFQUERY>
Note, too, that I've not bothered with any date formatting "mask". In my testing, Access is happy with the default dateformat form of date layout.
So when should you use the pound sign approach? Well, really, it's more something that's needed within Access itself to be able to detect that a string of numbers (and dashes or slashes) are in fact representing a date. The thing is, with the ODBCDateFormat function (and CF's Now() returning a date in ODBCDateTime Format), it's perhaps not as important to use the pound-surrounded approach to dates in Access.
Monday, November 11, 2002
Wow. A Contribute DesDev Site Already
Wow, there's already a DesDev site devoted to Contribute, with 23 articles. Check it out at http://www.macromedia.com/desdev/contribute/.
Subscribe to:
Posts (Atom)
