Uppercase (AccessXP 4.30)

Topic

New Reply

I’m feeling very ignorant and frustrated right now. I cannot get Access to STORE data in fields in uppercase. It displays that way. But when I export to dBase for example (using a query) my data is in lowercase. EXCEPT where I use >!! in my “State” field. What am I missing for my other text fields? I do have “>” in both format and mask. Anyone have any thoughts?

Thanks!

Reply | Quote

Replies

If you have an input mask with > for a field, the data in that field ought to be converted to upper case as you enter them, i.e. the value ought to be stored in upper case. Data existing before you set the input mask will not be modified, however.
The Format property is for display only, it has no effect on the way the data are stored.

You can take other measures:

– To ensure that existing data are converted to upper case, create an update query based on your table. Add all fields you want to convert to the query grid, then change the query to an update query (use the Query menu.) In the Update To cell for each field, enter UCase([NameOfField]) with the appropriate field name substituted.

– To ensure that new data are converted to upper case, you must use code in a form based on the table. Write an After Update event for each of the controls bound to a field you want to store in upper case:

Private Sub NameOfField_AfterUpdate()
Me.[NameOfField] = UCase(Me.[NameOfField])
End Sub

again, with the appropriate name substituted.

Reply | Quote

Thanks Hans!

The code worked beautifully.

And after a HUGE disaster by not writing the update query correctly, I did get it to work properly. Too bad the database backup was 8 days old instead of the 2 it should have

However, I was able to recover from that mess. And I’ll remember now to test my queries like that on sample data first to make sure it does what I want to.

Peggy

Reply | Quote

Umm, yes, it is always wise to test on a copy of the original database first.

Reply | Quote

Yes, I am certainly embarrassed on that.

But I was just wondering: what does the “me” stand for as in Me.[NameOfField]? Anything?

Peggy

Reply | Quote

In the code behind a form or report, “Me” stands for the form or report itself. Although the Me. is not strictly necessary, it has the advantage that the moment you type the period, IntelliSense kicks in and displays a list of available properties and methods, among which the controls. And by explicitly specifying that the control belongs to the form or report, the code becomes theoretically a little bit more efficient, because the VBA interpreter doesn’t need to look up what it belongs to. But I doubt you would notice the difference.

Reply | Quote

I understand what the “me” referred to. Just wondering why those particular letters and if they meant something. And it certainly does help when writing code to have the look available.

Reply | Quote

It’s “me” as in “I, me, mine”. These properties belong to Me.

Reply | Quote

Okay. That works for me (sorry!). One of life’s little mysteries is now solved and I can sleep tonight !

Reply | Quote

Okay. That works for me (sorry!). One of life’s little mysteries is now solved and I can sleep tonight !

Reply | Quote

It’s “me” as in “I, me, mine”. These properties belong to Me.

Reply | Quote

I understand what the “me” referred to. Just wondering why those particular letters and if they meant something. And it certainly does help when writing code to have the look available.

Reply | Quote

In the code behind a form or report, “Me” stands for the form or report itself. Although the Me. is not strictly necessary, it has the advantage that the moment you type the period, IntelliSense kicks in and displays a list of available properties and methods, among which the controls. And by explicitly specifying that the control belongs to the form or report, the code becomes theoretically a little bit more efficient, because the VBA interpreter doesn’t need to look up what it belongs to. But I doubt you would notice the difference.

Reply | Quote

Yes, I am certainly embarrassed on that.

But I was just wondering: what does the “me” stand for as in Me.[NameOfField]? Anything?

Peggy

Reply | Quote

Umm, yes, it is always wise to test on a copy of the original database first.

Reply | Quote

Thanks Hans!

The code worked beautifully.

And after a HUGE disaster by not writing the update query correctly, I did get it to work properly. Too bad the database backup was 8 days old instead of the 2 it should have

However, I was able to recover from that mess. And I’ll remember now to test my queries like that on sample data first to make sure it does what I want to.

Peggy

Reply | Quote

If you have an input mask with > for a field, the data in that field ought to be converted to upper case as you enter them, i.e. the value ought to be stored in upper case. Data existing before you set the input mask will not be modified, however.
The Format property is for display only, it has no effect on the way the data are stored.

You can take other measures:

– To ensure that existing data are converted to upper case, create an update query based on your table. Add all fields you want to convert to the query grid, then change the query to an update query (use the Query menu.) In the Update To cell for each field, enter UCase([NameOfField]) with the appropriate field name substituted.

– To ensure that new data are converted to upper case, you must use code in a form based on the table. Write an After Update event for each of the controls bound to a field you want to store in upper case:

Private Sub NameOfField_AfterUpdate()
Me.[NameOfField] = UCase(Me.[NameOfField])
End Sub

again, with the appropriate name substituted.

Reply | Quote