 | |
Working with dates in A2010
comp.databases.ms-access comp.databases.ms-access
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Working with dates in A2010 -
03-09-2010
, 06:45 PM
#2
| |||
| |||
|
#3
| |||
| |||
|
|
Curious. Are SQL statements query only or can one run on the fly a strSQL = "Select * From Customers" run the statement somehow? IOW, should most/all queries already be built beforehand? |
hardest feature we give up). So, you have to use set filter.
There also the ability to pass/feed queries with a new parameter
option we have.
Quote:
|
I read someplace you can have a maximum of 255 tempvars. Do you find that a sufficient amount? Or do you usually clean up/close your tempvars when a form closes since tempvars are global in scope? |
vars in those forms. And, data macros are also local vars. And, for
many tempvars, you can often re-cycle and re-use them. So, for
example, I often use lngID for the current form, and it quite rare
that I have many forms open in at the same time in web based systems
that would trip this code issue up.
At the end of the day, web applications are by nature going to be a
good deal simpler then rich desktop applications.
Quote:
|
I think I get your point. One could do a SetTempVar on a date and in the query extract the parts; day, month, year, hour, minutes, seconds. Forget the code, use a query. Is that the gist? |
the parts. I not calling some query. The simple issue is that if your form
has column like invoiceDate, then you just add a few extra columns to the
query called iYear, iMonth in the query builder. We then base the form on
that query.
So, we don't set any temp vars or anything, we just added those columns to
the query. So, those extra columns in the query builder would look like:
iYear: Year([InvoiceDate]) iMonth: ([InvoiceDate])
So, if our form is based on this query, then in macro code I can go:
MessageBox
=("The current invoice month is " & [iMonth])
So, I am not even calling the query. It just that the form now has 2 extra
columns with the year and month that we need. You could even drop those
columns on the form if you wanted the form to display the month, or year of
the invoice. So I am just basing the form on this query. I can thus use
those columns anywhere in the forms macro code and I have the month and year
value at my fingertips. Queries have a great function set, so you can use
that rich query function set to get those expressions back into forms and
also for use in your macro code.
As mentioned, it really depends if you talking about a bound column (that is
my above assumption here). I think in most cases, you using a where clause
(which thus has the date functions you need), or you passing to a data macro
(which again has the functions you need).
However, as the above shows, if you needed a message box to give you some
message with the current month value, then the above query trick is a simple
easy solution here.
Here is a screen shot of a web query, and again you can see the expressions
I building:
http://cid-b18a57cb5f6af0fa.skydrive...king/webqu.png
(note if you click a 2nd time on those pictures...they do zoom in).
And here is one that is using the hour function:
http://cid-b18a57cb5f6af0fa.skydrive...ng/webqury.png
(note above, I have the expression builder up, and you can see the function
set is very rich).
The function set in forms is very limited, but as the above shows, you can
well work around this issue..
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com
#4
| |||
| |||
|
|
I should point out that that macro code you write in a form, will actually be converted into Java. That code runs client side. I am repeat this!! That form code (or what we call a UI macro) runs as Java script inside of your browser |
almost nothing in common. Please don't confuse the issue by
erroneously mentioning Java in this context.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
#5
| |||
| |||
|
|
So not only are the Access forms running Java, it's a asynchronous so they are actually AJAX forms. |
They are not running Java.
They are running *JavaScript* which has almost nothing at all in
common with Java. NOTHING.
Please be more precise, Albert.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
#6
| |||
| |||
|
|
"Salad" <salad (AT) oilandvinegar (DOT) com> wrote in message news  8udnX86_YdUpgrWnZ2dnUVZ_tGdnZ2d (AT) earthlink (DOT) com...Curious. Are SQL statements query only or can one run on the fly a strSQL = "Select * From Customers" run the statement somehow? IOW, should most/all queries already be built beforehand? No sql on the fly. This feature is missed in web development (likely the hardest feature we give up). So, you have to use set filter. There also the ability to pass/feed queries with a new parameter option we have. I read someplace you can have a maximum of 255 tempvars. Do you find that a sufficient amount? Or do you usually clean up/close your tempvars when a form closes since tempvars are global in scope? It seems to be more then enough. Remember, you also have local vars in those forms. And, data macros are also local vars. And, for many tempvars, you can often re-cycle and re-use them. So, for example, I often use lngID for the current form, and it quite rare that I have many forms open in at the same time in web based systems that would trip this code issue up. At the end of the day, web applications are by nature going to be a good deal simpler then rich desktop applications. I think I get your point. One could do a SetTempVar on a date and in the query extract the parts; day, month, year, hour, minutes, seconds. Forget the code, use a query. Is that the gist? Well, it not that you would set a temp var and then "in the query" extract the parts. I not calling some query. The simple issue is that if your form has column like invoiceDate, then you just add a few extra columns to the query called iYear, iMonth in the query builder. We then base the form on that query. So, we don't set any temp vars or anything, we just added those columns to the query. So, those extra columns in the query builder would look like: iYear: Year([InvoiceDate]) iMonth: ([InvoiceDate]) So, if our form is based on this query, then in macro code I can go: MessageBox =("The current invoice month is " & [iMonth]) So, I am not even calling the query. It just that the form now has 2 extra columns with the year and month that we need. You could even drop those columns on the form if you wanted the form to display the month, or year of the invoice. So I am just basing the form on this query. I can thus use those columns anywhere in the forms macro code and I have the month and year value at my fingertips. Queries have a great function set, so you can use that rich query function set to get those expressions back into forms and also for use in your macro code. As mentioned, it really depends if you talking about a bound column (that is my above assumption here). I think in most cases, you using a where clause (which thus has the date functions you need), or you passing to a data macro (which again has the functions you need). However, as the above shows, if you needed a message box to give you some message with the current month value, then the above query trick is a simple easy solution here. Here is a screen shot of a web query, and again you can see the expressions I building: http://cid-b18a57cb5f6af0fa.skydrive...king/webqu.png (note if you click a 2nd time on those pictures...they do zoom in). And here is one that is using the hour function: http://cid-b18a57cb5f6af0fa.skydrive...ng/webqury.png (note above, I have the expression builder up, and you can see the function set is very rich). The function set in forms is very limited, but as the above shows, you can well work around this issue.. Thank you. Gotta wrap my brain around this. |
#7
| |||
| |||
|
|
"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote in news:ysGln.9197$NH1.1256 (AT) newsfe14 (DOT) iad: So not only are the Access forms running Java, it's a asynchronous so they are actually AJAX forms. NO NO NO NO NO. They are not running Java. They are running *JavaScript* which has almost nothing at all in common with Java. NOTHING. Please be more precise, Albert. |
However, I well just assumed mentioning AJAX implied this means java script.
However, you are correct. JavaScript is included with the browser and is
lightweight and requires no additional loading of software.
The java runtime implies a much heaver footprint and an very different
software experience and has a separate software installing requirement.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com
#8
| |||
| |||
|
|
"David W. Fenton" <XXXusenet (AT) dfenton (DOT) com.invalid> wrote in message news:Xns9D3795FCE50E9f99a49ed1d0c49c5bbb2 (AT) 74 (DOT) 209.136.94... "Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote in news:ysGln.9197$NH1.1256 (AT) newsfe14 (DOT) iad: So not only are the Access forms running Java, it's a asynchronous so they are actually AJAX forms. NO NO NO NO NO. They are not running Java. They are running *JavaScript* which has almost nothing at all in common with Java. NOTHING. Please be more precise, Albert. Agreed. However, I well just assumed mentioning AJAX implied this means java script. |
Quote:
|
However, you are correct. JavaScript is included with the browser and is lightweight and requires no additional loading of software. |
the fact that both are modelled on C-like conventions. When Netscape
created JavaScript, Sun's Java was really hot, and a threat to
Netscape's play for domination of the web, so Netscape licensed the
name and used it for their browser-embedded client-side scripting
language.
See http://en.wikipedia.org/wiki/JavaScript for the early history.
Until reading that, I didn't realize the name had been licensed and
that Sun still owned the name JavaScript.
Quote:
|
The java runtime implies a much heaver footprint and an very different software experience and has a separate software installing requirement. |
understand what they are. That's why it's so surprising that you
would repeatedly erroneously refer to JavaScript as Java, since I
know perfectly well you don't think you're writing Java when you're
using JavaScript.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.