Microsoft Access Team Blog : Power Tips

Use late binding to improve the performance of tabbed forms

cdowns — Wed, 09 Dec 2009 18:03:47 GMT

Luke Chung, President and Founder of FMS, Inc., has written and presented a wide range of topics related to Access over the years. In addition to their many Access related products, FMS offers a wealth of great Access papers, tips, and video on their site.

If you use the Tab Control to pack a lot of controls onto a form, here is a great tip to make the form load more quickly. The secret is in keeping most of the controls unbound until you need them. For example, on the form shown below, you could keep the controls on the Address, Telephone, and Other info tabs unbound until you click the tabs.

Check out this tip on the FMS site!

Become a guest blogger on the Access Team Blog! Send your Power Tips to Chris and Mike at accpower@microsoft.com.

The Cartesian product: a feature, not a bug

cdowns — Mon, 30 Nov 2009 23:46:51 GMT

Today's guest blogger is Access MVP Garry Robinson, who offers up another gem from the Smart Access collection of articles at http://www.vb123.com/kb.

In this article written by Peter Vogel, you will be given an overview about what it means to write queries where tables are not joined. This is a good thing to know because SQL queries written this way can help you now in exactly the same way as it did for Peter and I working on projects in the last century.

Article by Peter Vogel from 1997

When we first started using Access as our company’s end-user reporting tool, there were some unfortunate incidents. In one of those incidents, our president put two tables, each with about 100,000 records, in a query and clicked the Run button. His computer rumbled for about five minutes, sighed deeply, and locked up. So he did it again. After the fourth or fifth time, he decided that this repeated failure wasn’t accidental and called me to fix it.

What was happening, of course, was that he had failed to join any fields in the first table to any of the fields in the second table. When you put two tables in the same query without joining them, SQL’s default behavior is to give you a recordset that contains every combination of every record in both tables. This type of result set is called a Cartesian product. Because we had more than 100,000 records in each of the tables in this example, the big sigh the computer was making occurred when it discovered there wasn’t enough memory to hold the 10 billion records he was generating. In mathematical circles, this is known as the "law of large numbers:" if you multiply one large number by another large number you get a humongous number.

I explained what was happening and my boss’ immediate reaction was the one that most users have: he was the victim of a bug. I don’t think I ever really convinced him that it wasn’t a bug and that he had discovered the fundamental behavior that makes SQL work.

How SQL works

Back in the bad old days, there was no special SQL syntax for joining two tables together. Instead of using the Join keyword and coding this:

SELECT * 
FROM Table1 
INNER JOIN Table2 ON Table1.Field1 = Table2.Field2;

you simply added a Where clause to the SQL statement:

SELECT * 
FROM Table1 , Table2 
WHERE Table1.Field1 = Table2.Field2;

It’s important to see this in light of SQL’s default behavior. Simply putting two tables in a query like this:

SELECT * FROM Table1, Table2;

generates every possible combination of the rows in the two tables. A Where clause specifies which rows, out of all of those combinations, you’re interested in. In the sample case, it’s just the ones where Table1.Field1 equals Table2.Field2.

The Join keyword was added primarily to make it easier for query optimizers to determine the best strategy for retrieving the records—and also to introduce a standardized way of specifying outer joins (which every SQL implementation seemed to do differently). While the query optimizer may use the Join clause to work out some arcane way of retrieving the data, for the result to be valid it must match the result you would get if you generated every possible combination of rows and then went through those rows winnowing out the ones that don’t match the various Where clauses.

Useful results and No Joins Can Be A Feature

Sometimes you have to write your SQL code using Where clauses to specify how the tables in the query are related. If you’re joining two fields of incompatible types, for instance, you have no choice. If Field1 is a string and Field2 is an integer you can’t just drag Field1 over to Field2 in the Query Design window (well, you can, but the resulting query won’t run). What you have to do, after adding both tables to the query, is pull Field1 down to the query grid and give it a criteria of CStr([Field2]). The resulting SQL would look like this:

SELECT Table1.Field1, * 
FROM Table1, Table2Num 
WHERE Table1.Field1=CStr([Field2]);

This harks back to the original SQL method for joining tables. There are even occasions when you don’t want to join the tables in a query because you want to exploit the default behavior. This may occur when you’re loading a table with data. For instance, I have been trying to find a simple way to generate a round robin schedule for a hockey tournament. The first step of our solution is to load the tblGames table with all the possible games that could result from the teams in the tblTeams table playing each other. We do this by putting two unjoined copies of the Teams table in the same MakeTable query:

SELECT tblTeam.TeamName, tblTeam_1.TeamName 
INTO tblCombinations 
FROM tblTeam, tblTeam AS tblTeam_1;

This query creates a table of all the possible team combinations, including some impossible ones where a team ends up playing itself.

Here’s another example: at my company we have to keep track of the road graders we’re building. We build a grader in 65 separate steps and when a step is completed, we check off that step for that grader. I built the table for recording this information by using a query that takes a table of all the graders to be added and a table of every step, and then exploits SQL’s default behavior:

INSERT INTO tblStatus(Grader,Step) 
SELECT * FROM tblNewGraders, tblStepList

Once the table is built, recording progress is just a matter of the guys on the shop floor checking off each row as the grader finishes each step. It’s like I told my boss, when his computer kept blowing up trying to generate 10 billion records: "It isn’t a bug, it’s a feature." I don’t think he appreciated the usefulness of Cartesian product joins, but he had a memorable introduction to the fundamental nature of SQL.

If you like this article, read how Garry put this theory to good use in producing X-Y Grid queries for mining companies:

http://www.vb123.com/kb/200003_gr_space.htm

Become a guest blogger! Submit your tips to Mike and Chris at accpower@microsoft.com

Add color formatting to columns in Combo Boxes and List Boxes

cdowns — Tue, 17 Nov 2009 18:18:00 GMT

Today's guest blogger is Pavlo Pedan of ARGO Business Corp. He has 15 years of experience with Access and has a great site of tips at http://sites.google.com/site/msaccesscode/.

As we all know, a List Box control has a Fore Color property. It sets the fore color for column values and headers simultaneously. Also, we know that table and query fields have a Format property, where color formatting can be set. For example, you can format a number field as 0.00[Green].

As stated in Access 97, 2003 and 2007 help, "If you set a field's Format property in table Design view, Microsoft Access uses that format to display data in datasheets. It also applies the field's Format property to new controls on forms and reports."

So when creating a new Text Box control, the Text Box inherits the underlying field's Format property. However, List Boxes and Combo Boxes can also inherit this color formatting. And, it works for existing controls as well as new ones. You can change the Format property for a table field, and the new color will be inherited by an existing control (Text Box, List Box, or Combo Box).

The strange thing is, the List Box control has no Format property, and the Format property for the Combo Box control is not changed by the Format property of the underlying field. See a sample database here for some examples.

Using color formatting for list boxes and combo boxes definitely makes an application more attractive. One can set different columns into different colors, set different colors for header and items, and use a type of conditional formatting for empty values. For example, the Format property for Field2 in the picture above is: [Blue];@;"Empty"[Magenta]. This formatting overrides the Fore Color property of the control.

Such formatting is applicable not only for underlying tables, but for queries as well. Therefore, by choosing different queries for different List Boxes, we can have different sets of colors while referencing the same table.

However, some limitations apply. The above only seems to work for Access 97 and 2007 (and 2010?) but not for 2003. Also, it seems to work only for Text and Memo fields.

Have you experimented with this? If so, please post a comment!

Thank you,
Pavlo

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Sorting a Listbox Using Command Buttons

Mike Stowe — Fri, 13 Nov 2009 23:28:01 GMT

Today’s guest blogger is Daniel Lamarche. Daniel is the Training Director at ComboProjects, which specializes in providing custom training solutions in Microsoft Office products.

I always thought it was cool to be able to sort a list by clicking the column heading once, for ascending order then once more for descending order.

A while ago I decided to tackle this feature in an Access form.

The buttons above the field names are used to sort the list. The triangle pointing down means the column is in descending order.

Clicking on it again will sort that column in ascending order and the triangle will be pointing up. Like you are used to.

This project required a basic understanding of Access SQL and concatenating strings.

When you configure the Listbox using the Row Source property to specify the data that will appear in the list you are in fact creating a SQL statement.

Read the rest of the article and download a sample database here: http://www.comboprojects.com/articles/accSortingList/accSortingListbox.html

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Displaying Data From Related Tables on a Form

Mike Stowe — Fri, 06 Nov 2009 22:12:58 GMT

Today's guest blogger is Access MVP Scott Diamond. Scott is the principal of Diamond Computing Associates and the author of Microsoft Office Access 2007 VBA.

This is a very frequently discussed issue. But before I get into the methods, you need to understand one of the principles of relational databases. That principle is that data should exist in one place only. Having the same data in multiple tables is a violation of normalization. Related records are indicated by a Foreign Key within the record that holds the Primary Key value of the parent record. So when you want to have data from multiple tables on a data entry form, you set it up to display the data not store it in the form’s RecordSource.

There are basically four ways to display related data on a form; Subforms, the Column property, DLookups and Listboxes. Ill discuss each in turn and suggest where to use each.

Subforms

You can use a subform to display several fields from the related table. Create the form using the Subform wizard or create a separate form and place it on the main form as a subform (I generally create a separate form). Using the wizard, you go through the following steps.

Select whether to use an existing form or create a new one
If you are creating select the table and fields to use
Select the linking fields, usually accept the defaults Access proposes

You can customize the subform, so it looks like part of the main form, by removing record selectors, navigation buttons, borders etc. I use subforms when I want to display 4 or more fields from the related record. Another advantage of using subforms is where you have a One to Many relation. Using a Continuous Form or Datasheet View, you can display multiple related records at once.

Column Property

Generally Foreign Keys are entered by selecting the related value from a combobox. The combobox uses a query as it Rowsource. This query displays the records from that parent table. At the least, the query includes the primary key field as its bound column and a description field. However, you can add as many other fields from the table as you want. These fields can then be reference using the Column property. Click the Build button […] next to the Rowsource property to enter Query Design Mode. In Query Design Mode you can add tables and fields to the query. You can control what fields actually display in the pull down list by setting their Column Width. Setting the width of an individual column to 0" will hide that column (Note: Column widths are entered separated by a ; for each column listed in the column Count). The combobox will only display the first non zero length column after selection. The following properties of a combo are key to using combos in this way: RowSource (the list), Bound column (what's actual stored), Column Count (how many columns in the list, Column Widths (the size of each column in the list).

You can then set the ControlSource for an unbound control to:

[comboxname].Column(x)

Where comboxname is the name of the control and x is the number of the column in the query for that field. Note: the column count starts with 0 so the 3rd column is 2.

Since the combobox selects a single record, the Column property will also reflect a single record. I use this method if I need to display 3 or less values from the related record.

DLookups

DLookups allow you pull a value from a field in a specific record. It uses the syntax:

DLookup([fieldname],table/queryname,Criteria).

The Criteria is used to specify the record you want to return. Since the Comboxname will store the Foreign Key value you would use a criteria like:

[keyfield] = & [Comboboxname].

This would also be used as the controlsource of an unbound control. Each DLookup should only be returning data from a single record. If its possible that the DLookup might not find a matching record you should use it within a NZ (NullZero) function to prevent errors. I use DLookups when I need to pull data from different tables based on a key value.

Listboxes

A Listbox can have multiple columns with column headers. It also can be set to display multiple matching records. I will, sometimes, use a Listbox in place of a continuous form or datasheet subform. Listboxes will also display multiple matching records.

There are two exceptions to the rule of not repeating data in multiple tables. The first is the PK value. Obviously, that value has to be repeated as the FK to relate the records to each other. The other exception is time sensitive data. Sometimes you need to freeze data that will change over time. The best example of this is price data. For example: In an order entry application, you want to freeze the price at the time of the order. In such a case, you would have the Price field repeated in the OrderDetails table. Generally you would use the Column property for this and populate the control in the After Update event of the Products combo use code like:

Me.txtPrice = Me.cboProduct.Column(2)

These guidelines should help you build forms that preserve normalization and are well organized and easy for the user to use.

A better way to reference tab control pages

cdowns — Fri, 06 Nov 2009 02:38:54 GMT

In VBA, a common way to refer to the pages of a tab control is to use the Value property. However, Luke Chung, President of FMS Inc., recommends using the PageIndex property instead. Click here to find out why!

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Convert hexadecimal color codes so you can use them in code

cdowns — Mon, 26 Oct 2009 15:14:08 GMT

Today's guest blogger is Michael Merlin, Lead Software Developer at Electronic Communities.

I recently wasted an hour trying to set a field's Back Color property to the hex code generated by the color picker. I figured it out after some searching, but still nobody online had the exact correct answer. I wrote a function that lets you easily use the hex color in code. The secret is to swap the R and the B, and then convert the hex to long. Further explanation follows in the comments of the function.

Cheers!
Michael

Public Function HexColor(strHex As String) As Long

    'converts Hex string to long number, for colors
    'the leading # is optional

    'example usage
    'Me.iSupplier.BackColor = HexColor("FCA951")
    'Me.iSupplier.BackColor = HexColor("#FCA951")

    'the reason for this function is to programmatically use the
    'Hex colors generated by the color picker.
    'The trick is, you need to reverse the first and last hex of the
    'R G B combination and convert to Long
    'so that if the color picker gives you this color #FCA951
    'to set this in code, we need to return CLng(&H51A9FC)
    
    Dim strColor As String
    Dim strR As String
    Dim strG As String
    Dim strB As String
    
    'strip the leading # if it exists
    If Left(strHex, 1) = "#" Then
        strHex = Right(strHex, Len(strHex) - 1)
    End If
    
    'reverse the first two and last two hex numbers of the R G B values
    strR = Left(strHex, 2)
    strG = Mid(strHex, 3, 2)
    strB = Right(strHex, 2)
    strColor = strB & strG & strR
    HexColor = CLng("&H" & strColor)

End Function

Running an Access Parameter Query from Excel

Mike Stowe — Fri, 23 Oct 2009 08:56:00 GMT

Excel MVP Michael Alexander wanted to share this tip about running an Access parameter query from Excel. He describes the problem thusly:

An Access parameter query is a kind of interactive query that prompts you for criteria before the query is run. Parameter queries are useful when you need to ask the query different questions using different criteria each time you run it.

Now we all know you can pull data from Access into Excel using MS Query. The problem is that MS Query doesn't let you pull in Parameter queries. There may be a technical reason for this, but I like to think it's just Microsoft's way of keeping things interesting. After all, technical roadblocks are the spice of life.
If you've had enough spice, I'll show you a VBA workaround that will enable you to run an Access parameter query from Excel.

Click over to Michael’s blog to learn about his solution to the problem.

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Expand only the subdatasheets you want

cdowns — Wed, 21 Oct 2009 15:43:00 GMT

Today's guest blogger is Pavlo Pedan of ARGO Business Corp. He has 15 years of experience with Access and has a great site of tips at http://sites.google.com/site/msaccesscode/.

If you have a form that contains subdatasheets, you can use the following VBA command to expand all of them:

Forms![FormName]![SubFormName].Form.SubdatasheetExpanded = True

However, we often want only some of the subdatasheets to be expanded, based on
some criteria (for example - expand only if subdatasheets contain data.)

Watch a short video demo and download a demo database from this page. Make sure you have added a reference to the "Accessibility" library (%windir%\system32\oleacc.dll).

This has been tested on Access 2007.

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Using the ShowToolbar Method to Hide the Ribbon

Mike Stowe — Fri, 16 Oct 2009 21:31:29 GMT

Today’s guest blogger is Edwin Blancovitch. Edwin is president of Advanced Developers.net, creators of Easy Payroll, a software package to manage your human resources, payroll, scheduling, time and attendance needs.

I have been using the ribbon for the last two years and I like it so much, however there was a situation where I wanted to hide the ribbon. I used the Minimize the Ribbon command to hide it, but there was still some space being used by the Office button and the ribbon tabs.

After some experimentation and some research I found that I could use the ShowToolbar method to hide the ribbon. The following line of code makes the ribbon disappear completely, and allows you to see the application like in Office 2003, without the command bars.

DoCmd.ShowToolbar "Ribbon", acToolbarNo

That will make the ribbon disappear completely, and allow you to see the application like in Office 2003, without the command bars.

To display the ribbon again, use this code:

DoCmd.ShowToolbar "Ribbon", acToolbarYes

I wrote an article a long time ago for creating context command bars with VBA code, now it will be great to experiment by creating new command bars that go in the top menu. You can use context command bars in your forms, and make it work the way you wanted.

Nulls vs. zero-length strings: a Power Tip from the past

cdowns — Wed, 14 Oct 2009 18:48:12 GMT

Today's guest blogger is Access MVP Garry Robinson, who offers the Smart Access collection of articles at http://www.vb123.com/kb.

A few months ago I purchased the rights to publish the Smart Access magazine online and it is from that collection that I offer this tip from Paul Litwin, the first editor of Smart Access. At the end of that I provide a link to an editorial on Null Values written by the second editor Peter Vogel. It never hurts to get a refresher course on Null values, a necessary evil for database developers.

Tip by Paul Litwin from 1997

Even though Access considers Nulls and zero-length strings (ZLS) separate values, often developers wish to treat them as equivalent for the sake of an If...Then statement or some other stretch of code. One way to accomplish this is to write code like this:

' Not so efficient 
If IsNull(varAge) or varAge = "" Then
     ' do something 
End If

A better way to do this is:

' More efficient 
If Len(varAge & "") = 0 Then
     ' do something 
End If

This second version of the code is more efficient for two reasons. First, if varAge is Null, the code converts it into a ZLS by appending a ZLS to it. This lets us replace two tests with one. Second, it’s simply more efficient to check for a ZLS using Len(ZLS) = 0 rather than ZLS="".

You can use a variation of this technique if you ever need to place the value of a text box or a variant variable into a string. Strings can’t contain Null values, so you may be tempted to write code like this that first checks to see if the text box is Null:

' Another correct but slow method 
If IsNull(txtAge) Then
     strAge = "" 
Else     
     strAge = txtAge 
End If

A much faster way to do this is to use code like this instead:

' This is faster 
strAge = txtAge & ""

This code avoids doing the test altogether by setting the value to the concatenation of the text box and a ZLS. If the text box is Null, this converts it into a ZLS. If the text box is either a ZLS or a regular value, then the concatenation has no effect.

Read more on Nulls in Peter Vogels editorial here http://www.vb123.com/kb/200207_pv_ed.htm

Identifying the Record Selected on a Continuous Form

Mike Stowe — Wed, 07 Oct 2009 02:03:30 GMT

Regularly when we create databases for our customers we use continuous forms for data entry. The problem is, it’s often difficult for users to identify the record they’re working on a big continuous form with tons of records.

I’ve found a way to overcome this in just a few just quick steps that I’d like to share with you guys.

This is fully compatible with previous versions of Access, because I have been doing this my whole life. Actually, I just found it by mistake, while trying to create a conditional formatting event. We can do this with conditional formatting but this method is easier.

First select the continuous form.
Set the Back Color of all the controls in the detail section of the form to the color that you want to be displayed when the user clicks the control. In this example, I’m using #ADC0D9.
Set the Back Style property of all the controls in the detail section of the form to Transparent.

Now, when you display the object in form view you will see the selected control highlighted with the color you have selected in the Back Color property of the control.

YEAH, now all your users can easily identify the current selected record and even the selected control where the cursor is. That’s all, no code, no difficult conditional format to configure.

You can download a sample database that illustrates this method here.

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

3 new articles available on MSDN

cdowns — Mon, 05 Oct 2009 18:40:46 GMT

MSDN writer Sal Ricciardi alerted us to the availability of 3 new articles on MSDN, two written by Luke Chung of FMS Inc., and one co-written by Luke Chung and Dan Haught.

Title	Author(s)
Performance Tips To Speed Up Your Access 2007 Database	Luke Chung and Dan Haught
Error Handling and Debugging Tips for Access 2007, VB, and VBA	Luke Chung
Tips and Techniques for Queries in Access 2007	Luke Chung

Definitely bookmark these for future reference!

Send your Power Tips to Mike and Chris at accpower@microsoft.com.

Dynamically Resize a Subform Based on the Record Count

Mike Stowe — Wed, 30 Sep 2009 23:53:05 GMT

Today’s guest blogger is Vinny Malanga. Vinny is the CTO of IMI Software, Inc. , which specializes in software development for the real estate and property management industries.

Many Access developers implement subforms to display data. Most often, at design time, the developer sets the subform to a specific size. In many cases this is fine, but there are some instances where it would be preferable to dynamically resize the subform at runtime, based on the number of records that it contains, up to a maximum number. Once the maximum number of records is reached, a vertical scroll bar should appear allowing the user to scroll through the rest of the records. The maximum number is arbitrary and simply used to prevent the subform from exceeding a certain height.

I’ve provided a sample database that you can download here. The database contains a table, two forms - a parent form and a subform - and a module with the resize method.

In short, when the parent form loads, it calls a function on the subform which handles the resizing. It first retrieves the height of the header, footer and detail section of the subform. From there the subform is resized based on the height of the header, the height of the footer, and the height of the detail times the number of records. There are a couple of twips added to the total number to even out the border around the subform. Next, the record count of the underlying data source is retrieved. If the record count is greater than the maximum number of records you’ve defined, the ScrollBars property of the subform is set to 2 (Vertical Only), otherwise 0 or None. Lastly, in case there are any controls that exist under the subform, another function is called which repositions those controls based on the calculated height of the subform.

I hope some of you find this technique useful.

Tracing Function Calls in VBA

Mike Stowe — Thu, 24 Sep 2009 20:36:33 GMT

Today’s guest blogger is Joel Graff. Joel is a field engineer with the Illinois Department of Transportation (IDOT).

Often, I find when looking for the source of an error in VBA code, a function call trace which returns the path of function calls preceding the error to be invaluable. While more complete compilers provide this feature as a part of the IDE, it is, unfortunately, absent in VBA. To accommodate this, I’ve written my own function call stack classes to help me trace errors. This implementation is based on something I found online, though I have since lost the reference. I cannot give credit where credit is due, only note that the basic implementation is at least somewhat borrowed.

There are two classes I use: cErrStack and cErr.

cErrStack – Instanced as a global object, this provides the stack for procedure names as they are called. Procedures are added / removed (pushed / popped) from the stack as they come in and go out of scope. When an error occurs, the stack then contains, in order, the procedures called up to the procedure in which the error occurred. The cErrStack object returns the procedure name in which the error occurred and the trace path of function calls preceding the error with the methods ErrorProcedure() and Trace(). For higher-level error handling (where error handling occurs at the form level or only in main procedures), the ErrorProcedure() and Trace() routines will not provide correct information. In these cases, ErrorProcedureHistory() and TraceHistory() should be used instead.

cErr – Instanced at the procedure level, this object pushes the name of the procedure on the global error stack object (the cErrStack object). When the procedure terminates, the cErr object goes out of scope, triggering its Terminate() Event. This event then removes (pops) the terminating procedure’s name from the global error stack.

A sample error message may look like this:

Often, when I deploy a new database that hasn’t had all the bugs worked out, I write my error handling routine to automatically open an email and paste the above information into it. That way, users can send me the relevant error information automatically. I also use line numbers to help better identify problem code, though I didn’t implement them in this example.

The original implementation only allowed for trace information to be available in the procedure in which the error occurred. That is, if an error occurred in a function with no error handling, then by the time the error was passed back to the procedure which did handle it, the stack would no longer have accurate trace information. However, as one Access user pointed out to me, adding error trapping code to every function creates a lot of code bloat and isn’t really necessary. Better code practices suggest use of “high-level” error trapping – trapping in main functions or at the form level. To accommodate “high-level” error trapping, I added a second stack to the cErrStack class, which contains a “trace history”.

The idea is simple: When an error occurs in a function with no handling, the error is passed up the line until it is handled. That means that once an error occurs in higher level error handling, a “history” needs to be preserved until the error is handled. The class object does this by copying the contents of the immediate stack to the history stack when a “pop” occurs, and simply reassigning the history stack to the immediate stack when a “push” occurs. Thus, when an error occurs and is passed up the line to the handling procedure (a series of “pops” occur on the immediate stack), the history stack is preserved. Once a push occurs on the immediate stack (which presumably won’t happen until after the error is handled) the history stack is destroyed and referenced to the immediate stack.

Attached is a sample of how the application works. There are three scenarios. The first two (“Lefthand Error” and “Righthand Error”) are “immediate” error handling examples. The last one is a high-level error handling example.

Click the icon below to download the sample classes.