 | |
Access 2010 Contacts Web database template question.
comp.databases.ms-access comp.databases.ms-access
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: Access 2010 Contacts Web database template question. -
02-15-2011
, 01:14 PM
|
?"Salad" wrote in message news:TI-dnbeGHvikMcTQnZ2dnUVZ_uKdnZ2d (AT) earthlink (DOT) com... Excellent. I have two questions from above regarding the macro statement "IsNull([TempVars]![tmpFirstVisit]) And IsNull([ID])" I said: That seems odd. How can TmpFirstVistit be null when it hasn't been initialized? You replied: it is null when not yet initialized. So if I had a statement like If Isnull([Tempvars]![Junk]) and I haven't declared it (this being the first and Only reference to Junk in any macro within the database, it would evaluate as null? Declaration is not necessary? Correct, it is null and declaration is not necessary. Access 2007 macros also work this way. So, tempvars are null, and there is no option explicit or need to declare before first use. They are much considered variant type. It is however often a good idea to assign the tempvar a value so it's data type is set. So, this is much how macros work, and I do not believe this is any change from 2007 macros. Second, the statement has IsNUll([ID]). Looking at the form there is no ID field on the form. There is [ID] as part of the recordsource. You always been even in regular version of Access been able to reference columns in the database without having to place the control on the form, so this is nothing new. And you always been able to do this without using ME!ID or ME("ID"). You can also use [ID] or even ID However, I had a few cases where referencing the underlying column in Access web did not work, so I as a general rule I recommend placing the control on the form, and if you do not want users to see it, then set visible = false. the property sheet the name is "txtID". That is a sub form, and the form is NameCard No way, near as I can tell, of looking at the table structure as there's no design view of the table. The above is not clear to me? You are correct there is no design view for web tables, but I am not really sure as to what information you were trying to find in the table that you could not find anyway? That table view was also introduced in a2007. I would prefer the old design view, but the new table view was used since it has to connect and talk to SharePoint. But it's an autonumber. So, ControlSource ID, Name txtID. A little odd. Actually, a good number of Access developers as a general rule use different names for the text box and controls as compared to what the underlying columns are. This development approach ensures that there is no confusing when you reference a control vs that of column in the table. Anyway txtID is an invisible field. I would have thought the IsNull([ID]) would be IsNull([txtID]). No, because that is an sub form and the code we talking about is running in the main form. And, I betting that the control is not visible since as I noted often I seen problems when you try to use a value of the underlying table without a control. So, in this case, the control txtID is placed on the form, but we are talking about a different form here (NameCard), while the on load code is running in the parent form called Contact Card. |
#12
| |||
| |||
|
|
So, tempvars are null, and there is no option explicit or need to declare before first use. They are much considered variant type. It is however often a good idea to assign the tempvar a value so it's data type is set. |
understand why, since the translation issues to the browser are not
going to allow strong typing, but it's nonetheless a step backward,
and a reason to not just switch to creating web databases as a
matter of course.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#13
| |||
| |||
|
|
You always been even in regular version of Access been able to reference columns in the database without having to place the control on the form, so this is nothing new. And you always been able to do this without using ME!ID or ME("ID"). You can also use [ID] or even ID However, I had a few cases where referencing the underlying column in Access web did not work, so I as a general rule I recommend placing the control on the form, and if you do not want users to see it, then set visible = false. |
between the form and the bound recordsource has been getting
flimsier and flimsier. In A2000, problems of this nature were first
introduced, but were mostly limited to references between parent
forms and subforms. By A2003, the problem had spread, and now it is
really completely unreliable to attempt to refer to a field in a
recordsource that is not bound to a control, hidden or not.
And it's actually been impossible in VBA code in reports since A2000
(it worked fine before then).
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#14
| |||
| |||
|
|
"Albert D. Kallal" <PleaseNOOOsPAMmkallal (AT) msn (DOT) com> wrote in news:ckz6p.9023$7P3.980 (AT) newsfe21 (DOT) iad: So, tempvars are null, and there is no option explicit or need to declare before first use. They are much considered variant type. Well, that's a step backwards, i.e., to an untyped environment. I understand why, since the translation issues to the browser are not going to allow strong typing, but it's nonetheless a step backward, and a reason to not just switch to creating web databases as a matter of course. |
However, I am not so sure that the adding of TempVars in access 2007 macros
was done with the web and Access 20109 macros in mind.
Part of the problem here is VBA was not going to the web. So, we would be
faced with needing several systems here:
Some type of Editor and language to allow writing of code that runs server
side (T sql for example?)
Some type of Editor and language to allow writing of code that runs browser
side
Some type of Editor and language to edit and write the new ACE triggers and
store procedural code
Some type of Editor to allow editing of VBA
Some type of Editor to allow writing of macros that access has always had.
By adopting the Macro language then we back down to the two languages (VBA
and macros) that Access always had.
And with two languages, then the learning curve is kept short and only two
editors are required. (keeping compatibility with previous macro code was
needed here).
My personal view is that for the web, I think we should be given a choice to
write code in vb.net for Access web forms in addition to the current macro
language. The question then becomes what IDE would be used to edit this
vb.net code with help + intelisense etc.?
The new Access macros are very cool in that one can be up and running and
writing web systems with a short learning curve. The problem here is when
additional complexity is required, or even having some type of formalized
development environment, then most developers would choose VBA over macros.
So, just like we now choose VBA over macros, I think the same type of choice
should exist for Access Web forms. And I think if the language was vb.net in
a simplified IDE, then I think the learning curve for vb.net would be rather
short since most event code in a form is not too complex anyway.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com
#15
| |||
| |||
|
|
By A2003, the problem had spread, and now it is really completely unreliable to attempt to refer to a field in a recordsource that is not bound to a control, hidden or not. |
had any problems.
In fact this works fine without controls placed on the form, and even when
the recordsource of the form is changed at runtime.
For me.ColumnName, they tend to break when the recordsource is changed.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com
#16
| |||
| |||
|
|
?"David-W-Fenton" wrote in message news:Xns9E8DD612A23EEf99a49ed1d0c49c5bbb2 (AT) 74 (DOT) 209.136.95... By A2003, the problem had spread, and now it is really completely unreliable to attempt to refer to a field in a recordsource that is not bound to a control, hidden or not. I still use me!CollumnName in my code. This has worked for me and I never had any problems. In fact this works fine without controls placed on the form, and even when the recordsource of the form is changed at runtime. |
if it isn't (or, break often enough that you have to avoid it).
Quote:
|
For me.ColumnName, they tend to break when the recordsource is changed. |
hidden property wrappers, which gives you compile-time checking, and
changing the Recordsource will very often invalidate existing
property wrappers. I never use it, so don't know the upshot of all
of that.
--
David W. Fenton http://www.dfenton.com/
contact via website only 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.