Prev: Outlook Read Receipt
Next: Subquery/report with check boxes
From: Tom van Stiphout on 29 May 2010 10:45
On Fri, 28 May 2010 21:24:42 -0400, "Arvin Meyer" <arvinm(a)invalid.org>
wrote:

Hi Arvin,
What is your definition of Alpha?
From your function it seems to be about the first character in the
string to be [a-zA-Z]. There are other definitions out there.

-Tom.
Microsoft Access MVP


>I would use text, then use IsNumeric() to determine if it's a number. I have
>also written a custom function to determine alpha (it's in my book <g>)
>
>Public Function fIsAlpha(varIn As Variant) As Boolean
>On Error Resume Next
>
> fIsAlpha = Not Asc(LCase(Left(varIn, 1))) = Asc(UCase(Left(varIn, 1)))
>
>Exit_Here:
> Exit Function
>
>End Function
From: Lars Brownies on 29 May 2010 12:20
> you would be better with this structure
> tblUserPreference
> UserID*
> PreferenceID*
> PreferenceValue <- this is text, store numbers as text
>
> tblPreference
> PreferenceID*
> PreferenceName
> PreferenceType <-use this to store the value's type (number or text)
> PreferenceGroup
> PreferenceDefault <- see PreferenceValue
>
> Only store non-default preferences in TblUserPreferences.
> dLookup the user's preference value for a specified PreferenceId, if
> null use the default from tblPreferences.
> Use the PreferenceType to control which conversion function to apply
> to the value (cInt, cBool, cDouble, etc.)

Thanks Bob,
I was a bit too hasty when typing the fieldnames. Indeed that was the idea.

The problem is that I want to present the preference possibilities to the
user as in other windows programs (Extra-Options etc.). So every preference
must be visible as a field, also if a user hasn't set a value for it. I
can't think of a query that gives the right result and remains editable as
well.

Other thing is that I want to use checkboxes for some preferences and I see
no way of doing that when I store all values in a text field.

Lars


"Bob Quintal" <rquintal(a)sPAmpatico.ca> schreef in bericht
news:Xns9D875A45C2268BQuintal(a)69.16.185.250...
> "Lars Brownies" <Lars(a)Browniew.com> wrote in
> news:htpit3$2rhe$1(a)textnews.wanadoo.nl:
>
>> I want users to be able to store personal preferences for paths,
>> layout, report dates, etc. I'm thinking to store the info in the
>> following tables
>>
>> tblUser
>> UserID*
>> UserLastnam
>> etc.
>>
>> tblUserPreference
>> UserID*
>> PreferenceID*
>>
>> tblPreference
>> PreferenceID*
>> PreferenceName
>> PreferenceGroup
>> PreferenceValue
>>
>> Problem is that I need to store values of different data types in
>> the field PreferenceValue.
>>
>> My questions are:
>> - How do I deal with the diffences in data type? Should I add a
>> field for every data type?
>> - If I enter a new user should I automatically add all Preferences
>> to him or should I only add a preference if he wants to differ
>> from the default value? - Or shouldn't I bother with normalisation
>> in this case?
>>
>> Thanks,
>>
>> Lars
>>
> you would be better with this structure
> tblUserPreference
> UserID*
> PreferenceID*
> PreferenceValue <- this is text, store numbers as text
>
> tblPreference
> PreferenceID*
> PreferenceName
> PreferenceType <-use this to store the value's type (number or text)
> PreferenceGroup
> PreferenceDefault <- see PreferenceValue
>
> Only store non-default preferences in TblUserPreferences.
> dLookup the user's preference value for a specified PreferenceId, if
> null use the default from tblPreferences.
> Use the PreferenceType to control which conversion function to apply
> to the value (cInt, cBool, cDouble, etc.)
>
From: Bob Quintal on 29 May 2010 16:35
"Lars Brownies" <Lars(a)Browniew.com> wrote in
news:htrese$ha1$1(a)textnews.wanadoo.nl:

>> you would be better with this structure
>> tblUserPreference
>> UserID*
>> PreferenceID*
>> PreferenceValue <- this is text, store numbers as text
>>
>> tblPreference
>> PreferenceID*
>> PreferenceName
>> PreferenceType <-use this to store the value's type (number or
>> text) PreferenceGroup
>> PreferenceDefault <- see PreferenceValue
>>
>> Only store non-default preferences in TblUserPreferences.
>> dLookup the user's preference value for a specified PreferenceId,
>> if null use the default from tblPreferences.
>> Use the PreferenceType to control which conversion function to
>> apply to the value (cInt, cBool, cDouble, etc.)
>
> Thanks Bob,
> I was a bit too hasty when typing the fieldnames. Indeed that was
> the idea.
>
> The problem is that I want to present the preference possibilities
> to the user as in other windows programs (Extra-Options etc.). So
> every preference must be visible as a field, also if a user hasn't
> set a value for it. I can't think of a query that gives the right
> result and remains editable as well.

You have the TblPreferences to start with. A form could show the
PreferenceName Field in a listbox, allowing the user to click on one
and poping up a form that shows the name, mayh some help text and has
a textbox/checkbox/calendar/whatever to receive user input, the type
being tied to the PreferenceType field. A save button then runs an
appen or update query to add to TblUserPreferences, then closes the
popup, and if necessary, requeries the listbox...

>
> Other thing is that I want to use checkboxes for some preferences
> and I see no way of doing that when I store all values in a text
> field.
>
a Checkbox can contain only true or false. Thets -1 and 0 as a
number, "T" of "F" as text, "Y" or "N" as text. what you need is a
small function to translete "T" to -1 and "N" to 0.

It is similar to the function required to translate "-7654321" to
-7654321

> Lars
>
>
> "Bob Quintal" <rquintal(a)sPAmpatico.ca> schreef in bericht
> news:Xns9D875A45C2268BQuintal(a)69.16.185.250...
>> "Lars Brownies" <Lars(a)Browniew.com> wrote in
>> news:htpit3$2rhe$1(a)textnews.wanadoo.nl:
>>
>>> I want users to be able to store personal preferences for paths,
>>> layout, report dates, etc. I'm thinking to store the info in the
>>> following tables
>>>
>>> tblUser
>>> UserID*
>>> UserLastnam
>>> etc.
>>>
>>> tblUserPreference
>>> UserID*
>>> PreferenceID*
>>>
>>> tblPreference
>>> PreferenceID*
>>> PreferenceName
>>> PreferenceGroup
>>> PreferenceValue
>>>
>>> Problem is that I need to store values of different data types
>>> in the field PreferenceValue.
>>>
>>> My questions are:
>>> - How do I deal with the diffences in data type? Should I add a
>>> field for every data type?
>>> - If I enter a new user should I automatically add all
>>> Preferences to him or should I only add a preference if he wants
>>> to differ from the default value? - Or shouldn't I bother with
>>> normalisation in this case?
>>>
>>> Thanks,
>>>
>>> Lars
>>>
>> you would be better with this structure
>> tblUserPreference
>> UserID*
>> PreferenceID*
>> PreferenceValue <- this is text, store numbers as text
>>
>> tblPreference
>> PreferenceID*
>> PreferenceName
>> PreferenceType <-use this to store the value's type (number or
>> text) PreferenceGroup
>> PreferenceDefault <- see PreferenceValue
>>
>> Only store non-default preferences in TblUserPreferences.
>> dLookup the user's preference value for a specified PreferenceId,
>> if null use the default from tblPreferences.
>> Use the PreferenceType to control which conversion function to
>> apply to the value (cInt, cBool, cDouble, etc.)
>>

From: Lars Brownies on 29 May 2010 17:20
> You have the TblPreferences to start with. A form could show the
> PreferenceName Field in a listbox, allowing the user to click on one
> and poping up a form that shows the name, mayh some help text and has
> a textbox/checkbox/calendar/whatever to receive user input, the type
> being tied to the PreferenceType field. A save button then runs an
> appen or update query to add to TblUserPreferences, then closes the
> popup, and if necessary, requeries the listbox...

Thanks for the idea. I was actully heading for a more Office like GUI, not
with a lisbox.

>> Other thing is that I want to use checkboxes for some preferences
>> and I see no way of doing that when I store all values in a text
>> field.
>>
> a Checkbox can contain only true or false. Thets -1 and 0 as a
> number, "T" of "F" as text, "Y" or "N" as text. what you need is a
> small function to translete "T" to -1 and "N" to 0.
>
> It is similar to the function required to translate "-7654321" to
> -7654321

I know how to do that. The reason I mentioned it was because my intention
was to let the user enter the value in the field itself on the basis of a
query. Since in a continuous form you can't have the same field be a textbox
in one record and a checkbox in another record. I'll do some more fiddling
to see which option to choose.

Lars


"Bob Quintal" <rquintal(a)sPAmpatico.ca> schreef in bericht
news:Xns9D87A8D089DC9BQuintal(a)69.16.185.250...
> "Lars Brownies" <Lars(a)Browniew.com> wrote in
> news:htrese$ha1$1(a)textnews.wanadoo.nl:
>
>>> you would be better with this structure
>>> tblUserPreference
>>> UserID*
>>> PreferenceID*
>>> PreferenceValue <- this is text, store numbers as text
>>>
>>> tblPreference
>>> PreferenceID*
>>> PreferenceName
>>> PreferenceType <-use this to store the value's type (number or
>>> text) PreferenceGroup
>>> PreferenceDefault <- see PreferenceValue
>>>
>>> Only store non-default preferences in TblUserPreferences.
>>> dLookup the user's preference value for a specified PreferenceId,
>>> if null use the default from tblPreferences.
>>> Use the PreferenceType to control which conversion function to
>>> apply to the value (cInt, cBool, cDouble, etc.)
>>
>> Thanks Bob,
>> I was a bit too hasty when typing the fieldnames. Indeed that was
>> the idea.
>>
>> The problem is that I want to present the preference possibilities
>> to the user as in other windows programs (Extra-Options etc.). So
>> every preference must be visible as a field, also if a user hasn't
>> set a value for it. I can't think of a query that gives the right
>> result and remains editable as well.
>
> You have the TblPreferences to start with. A form could show the
> PreferenceName Field in a listbox, allowing the user to click on one
> and poping up a form that shows the name, mayh some help text and has
> a textbox/checkbox/calendar/whatever to receive user input, the type
> being tied to the PreferenceType field. A save button then runs an
> appen or update query to add to TblUserPreferences, then closes the
> popup, and if necessary, requeries the listbox...
>
>>
>> Other thing is that I want to use checkboxes for some preferences
>> and I see no way of doing that when I store all values in a text
>> field.
>>
> a Checkbox can contain only true or false. Thets -1 and 0 as a
> number, "T" of "F" as text, "Y" or "N" as text. what you need is a
> small function to translete "T" to -1 and "N" to 0.
>
> It is similar to the function required to translate "-7654321" to
> -7654321
>
>> Lars
>>
>>
>> "Bob Quintal" <rquintal(a)sPAmpatico.ca> schreef in bericht
>> news:Xns9D875A45C2268BQuintal(a)69.16.185.250...
>>> "Lars Brownies" <Lars(a)Browniew.com> wrote in
>>> news:htpit3$2rhe$1(a)textnews.wanadoo.nl:
>>>
>>>> I want users to be able to store personal preferences for paths,
>>>> layout, report dates, etc. I'm thinking to store the info in the
>>>> following tables
>>>>
>>>> tblUser
>>>> UserID*
>>>> UserLastnam
>>>> etc.
>>>>
>>>> tblUserPreference
>>>> UserID*
>>>> PreferenceID*
>>>>
>>>> tblPreference
>>>> PreferenceID*
>>>> PreferenceName
>>>> PreferenceGroup
>>>> PreferenceValue
>>>>
>>>> Problem is that I need to store values of different data types
>>>> in the field PreferenceValue.
>>>>
>>>> My questions are:
>>>> - How do I deal with the diffences in data type? Should I add a
>>>> field for every data type?
>>>> - If I enter a new user should I automatically add all
>>>> Preferences to him or should I only add a preference if he wants
>>>> to differ from the default value? - Or shouldn't I bother with
>>>> normalisation in this case?
>>>>
>>>> Thanks,
>>>>
>>>> Lars
>>>>
>>> you would be better with this structure
>>> tblUserPreference
>>> UserID*
>>> PreferenceID*
>>> PreferenceValue <- this is text, store numbers as text
>>>
>>> tblPreference
>>> PreferenceID*
>>> PreferenceName
>>> PreferenceType <-use this to store the value's type (number or
>>> text) PreferenceGroup
>>> PreferenceDefault <- see PreferenceValue
>>>
>>> Only store non-default preferences in TblUserPreferences.
>>> dLookup the user's preference value for a specified PreferenceId,
>>> if null use the default from tblPreferences.
>>> Use the PreferenceType to control which conversion function to
>>> apply to the value (cInt, cBool, cDouble, etc.)
>>>
>
From: Access Developer on 29 May 2010 17:45
In the past, I've used a table in the front-end, a table in the back-end,
and an .ini file for this purpose. The first worked well for individual
preferences if the user only ever used the app from their own computer. The
second worked well when users might use the app from different computers,
and just as well if they only used one.

It's been so long since I used the .INI that I really don't remember what I
thought about using it -- back in Access 2.0 days. There were (are? don't
know if they were dropped in Vista and Win 7) APIs for accessing personal
and database-level INIs.

You can use the <the very thought of it makes me queasy> Registry, or define
Properties for the database (front-end?) to store preferences -- but I
haven't used the last two.

--
Larry Linson, Microsoft Office Access MVP
Co-author: "Microsoft Access Small Business Solutions", published by Wiley
Access newsgroup support is alive and well in USENET
comp.databases.ms-access


"Lars Brownies" <Lars(a)Browniew.com> wrote in message
news:htpit3$2rhe$1(a)textnews.wanadoo.nl...
>I want users to be able to store personal preferences for paths, layout,
>report dates, etc. I'm thinking to store the info in the following tables
>
> tblUser
> UserID*
> UserLastnam
> etc.
>
> tblUserPreference
> UserID*
> PreferenceID*
>
> tblPreference
> PreferenceID*
> PreferenceName
> PreferenceGroup
> PreferenceValue
>
> Problem is that I need to store values of different data types in the
> field PreferenceValue.
>
> My questions are:
> - How do I deal with the diffences in data type? Should I add a field for
> every data type?
> - If I enter a new user should I automatically add all Preferences to him
> or should I only add a preference if he wants to differ from the default
> value?
> - Or shouldn't I bother with normalisation in this case?
>
> Thanks,
>
> Lars
>
>
>
>
>


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Outlook Read Receipt
Next: Subquery/report with check boxes