P. 1
Access Tutorial

Access Tutorial

|Views: 18|Likes:
Published by raymond_gacab

More info:

Published by: raymond_gacab on Sep 13, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less






We will now the professional solution. We don't
change Value at all, but compute the SQL-statement to
be used for the stay list. Let us first assume that the
user has entered the search criterion john. The event
procedure could then compute the list of stays in this

Me.subStayList.Form . RecordSource = _
"select * from qryStayList where name like ( '*john*' );"

This is one long Visual Basic statement split into two
lines by means of the space and underscore at the end
of the first line.

Now, what does the statement do? The first line refers
to the open form in subStayList. The form has a record
source property, which defines the records to display.
We had bound the form to qryStayList, so the record
source was "qryStayList".

Now the procedure changes the record source to the
SQL statement in the second line. This statement takes
all records in qryStayList where the name contains
john. And it selects all attributes from the records. This
is what we need.

Notice that the SQL statement is a text surrounded by
double quotes. Inside the statement we have another
text string '*john*'. This text string is surrounded by
single quotes to distinguish it from the large text. We
haven't cared to write SELECT etc. with caps. The
SQL engine accepts the statement anyway.

The only problem is that john should be the text that
the user has entered. So the event procedure has to
compose the SQL statement from three parts, like this:

"select * from qryStayList where name like ('*" & _
Me.txtName.Text & "*');"

Note: Some developers don't use single quotes for the
text inside the text. They use double quotes for the
inner text. So instead of

" . . . like ('*" &

they would write

" . . . like (""*" &

The rule is that inside a text string, the characters ""
mean a single ".

Try it out

You may try the solution right away, but take care. The
next time you open frmFindStay and try to search,
Access remembers the SQL statement your program
has set. It uses this statement as the initial query for the
future. (I would call this an error.)

To avoid problems do as follows:

1. In qryStayList, remove the user criterion that we
defined earlier (like . . . ). We don't need it any-

2. In fsubStayList, the record source is qryStayList.
Change it to select * from qryStayList;

3. Change the event procedure and try it out (see
Figure 5.2B).

You should now have a live search similar to the one
used in the real system.

(If Access still remembers the previous search crite-
rion, open frmFindStay in design mode and set once
more the Source Object of subStayList to fsubStayList.)

Computed SQL may seem very cumbersome. Yes - it
is, no doubt! However, when we need complex user
criteria, for instance a combination of name and/or
phone and/or date, the easiest way is to let the program
compute the SQL statement. In general, computed SQL
is the professional way to make complex systems.

In the next section we will use computed SQL to deal
with combinations of search criteria, some of them live
and some lazy.

5. Access through Visual Basic


Fig 5.2B Computed SQL and live search

Define new
record source

To make it work properly:

Remove the old user criterion from qryStayList.

Set record source of fsubStayList to: select * from qryStayList;

Change the event procedure as above. Try it out.

Compute SQL from
part1 & part2 & part3

Note single quotes
around inner text strings


5. Access through Visual Basic

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->