In tables design view I have a short text field that I want in Red
Bold.

Where is the formatting code to put the Red Bold?
Is there an extensive list of other format codes?

Peter

In article <r82cfh1qqukd7mg22itt08hukphv999kaq@4ax.com>, Peter Jason wrote...
>
> In tables design view I have a short text field that I want in Red
> Bold.
>
> Where is the formatting code to put the Red Bold?
> Is there an extensive list of other format codes?
>
> Peter

It's become conventional to have a separation between raw data and display
considerations. In modern web design a page is structured with HMTL (shunning
legacy formatting features) with presentation controlled using CSS (Cascading
Style Sheets). Similarly in Access, the table design view has no presentation
formatting other than that which controls the way numerics are to be shown:
percentage, currency, date (stored as a number) and so on. If you wanted to
associate in your data a colour with, say, a type of grocery item, you'd need a
table with the class of item and a colour value.

But that would be an unusual thing to do in Access, which provides forms and
reports to handle presentation, and it's actually rare to expect users to
interact with data tables directly. You can base a form or a report on a
table, or from a query which can select desired rows and columns from one or
more tables. It's easier to do than many think, and if you don't like the
result, you can safely delete the form or report leaving your underlying data
unchanged. There are wizards, and lots of good videos on YouTube. Typically,
you can get something you're surprisingly pleased with up in a few minutes, and
then you spend the rest of your life turning it into a work of art... (ask me
how I know.)

--

Phil, London

On Fri, 12 Aug 2022 10:37:28 +0100, Philip Herlihy
<PhillipHerlihy@SlashDevNull.invalid> wrote:

>In article <r82cfh1qqukd7mg22itt08hukphv999kaq@4ax.com>, Peter Jason wrote...
>>
>> In tables design view I have a short text field that I want in Red
>> Bold.
>>
>> Where is the formatting code to put the Red Bold?
>> Is there an extensive list of other format codes?
>>
>> Peter
>
>It's become conventional to have a separation between raw data and display
>considerations. In modern web design a page is structured with HMTL (shunning
>legacy formatting features) with presentation controlled using CSS (Cascading
>Style Sheets). Similarly in Access, the table design view has no presentation
>formatting other than that which controls the way numerics are to be shown:
>percentage, currency, date (stored as a number) and so on. If you wanted to
>associate in your data a colour with, say, a type of grocery item, you'd need a
>table with the class of item and a colour value.
>
>But that would be an unusual thing to do in Access, which provides forms and
>reports to handle presentation, and it's actually rare to expect users to
>interact with data tables directly. You can base a form or a report on a
>table, or from a query which can select desired rows and columns from one or
>more tables. It's easier to do than many think, and if you don't like the
>result, you can safely delete the form or report leaving your underlying data
>unchanged. There are wizards, and lots of good videos on YouTube. Typically,
>you can get something you're surprisingly pleased with up in a few minutes, and
>then you spend the rest of your life turning it into a work of art... (ask me
>how I know.)

Thanks, I've always used Access from Access97, and sometimes I can get
some colloguing in the fields. In the screen below I have done this.
Trouble is I depend nearly always on the Wizards, but have been known
to use cut/paste VBA code. I have been stumped by the 3-level Bill of
Materials (BOM) a consultant installed for me ages ago (now he's
disappeared). Do you know of an Access equivalent 3-level BOM
template?
https://postimg.cc/Y4b57Krz

In article <h00efhl398msu722ginru8qh6lsgagbqbq@4ax.com>, Peter Jason wrote...
>
> On Fri, 12 Aug 2022 10:37:28 +0100, Philip Herlihy
> <PhillipHerlihy@SlashDevNull.invalid> wrote:
>
> >In article <r82cfh1qqukd7mg22itt08hukphv999kaq@4ax.com>, Peter Jason wrote...
> >>
> >> In tables design view I have a short text field that I want in Red
> >> Bold.
> >>
> >> Where is the formatting code to put the Red Bold?
> >> Is there an extensive list of other format codes?
> >>
> >> Peter
> >
> >It's become conventional to have a separation between raw data and display
> >considerations. In modern web design a page is structured with HMTL (shunning
> >legacy formatting features) with presentation controlled using CSS (Cascading
> >Style Sheets). Similarly in Access, the table design view has no presentation
> >formatting other than that which controls the way numerics are to be shown:
> >percentage, currency, date (stored as a number) and so on. If you wanted to
> >associate in your data a colour with, say, a type of grocery item, you'd need a
> >table with the class of item and a colour value.
> >
> >But that would be an unusual thing to do in Access, which provides forms and
> >reports to handle presentation, and it's actually rare to expect users to
> >interact with data tables directly. You can base a form or a report on a
> >table, or from a query which can select desired rows and columns from one or
> >more tables. It's easier to do than many think, and if you don't like the
> >result, you can safely delete the form or report leaving your underlying data
> >unchanged. There are wizards, and lots of good videos on YouTube. Typically,
> >you can get something you're surprisingly pleased with up in a few minutes, and
> >then you spend the rest of your life turning it into a work of art... (ask me
> >how I know.)
>
> Thanks, I've always used Access from Access97, and sometimes I can get
> some colloguing in the fields. In the screen below I have done this.
> Trouble is I depend nearly always on the Wizards, but have been known
> to use cut/paste VBA code. I have been stumped by the 3-level Bill of
> Materials (BOM) a consultant installed for me ages ago (now he's
> disappeared). Do you know of an Access equivalent 3-level BOM
> template?
> https://postimg.cc/Y4b57Krz

I'm afraid I don't.

I looked at your screenshot, and yes, that's a form, not a table - you can
certainly make forms colourful (etc.).

Access is certainly very powerful, and it's hard to imagine how to build an
application like yours without an underlying database. For custom applications
for small-to-medium businesses, Access is marvellous.

But it needs "safe hands". An ill-constructed database can mangle your data so
comprehensively that it might as well be encrypted. If you need to rely on
that data, then you need to invest in your database - just as if you rely on a
vehicle for deliveries to customers, it's best to get it serviced by someone
who really knows what they are doing, and maybe to plan for its replacement in
time.

So keeping your system going is going to need you to go in one of two
directions - either you skill yourself up to a level when you're writing things
rather than copying them, or hiring someone to do the work for you. I'm an
Access developer (retired, and now quite rusty) and the going rate for such
work is not trivial - it's intricate work demanding evolved skills. In Usenet
(here!) there used to be several groups where real experts hung out and were
prepared to share their understanding. But this group seems to be all that
remains, and this one is pretty quiet. I have to say I don't know where you'd
go to link up with expert advice - though I guess there must be somewhere! The
web-based forums I've seen do have a much reduced signal-to-noise ratio, and
official "support" forums seem staffed by clueless interns whose principal
concern appears to be excruciating over-politeness.

There are books, and the former Lynda.com videos (now on LinkedIn) are very
good indeed. Access is huge fun to learn and master, but the more you master
it the more you become aware of possible errors you may have made in the past.
Get your table design right ("normalised") and the battle's half-won. It is
impossible to over-emphasise that point - a bad table design means you're
condemned to work around it.

One real problem with custom code is that it isn't always (often?) well-
documented, and it can be hard to figure out how it's supposed to work.
Sometimes it can feel (and even be) easier to scrap an existing version and
start again. As a trained software engineer, I once delivered a one-line
shell-script with two full A4 pages of explanatory text; my successor was
eventually effusively grateful! Access doesn't particularly lend itself either
to prompting developers to document it, or to reverse-engineering.

It's hard to know what useful advice to offer. I'd encourage you to continue
to build your skills in Access - you clearly have what it takes, though you may
need to invest time in working systematically towards mastery. I'd figure you
probably need another consultant to fix your BOM functionality, and (in keeping
with the importance to your business) that won't be cheap. Unless it's really
urgent, I'd spend some time simultaneously building your skills (those LinkedIn
courses are good, and there are other online training providers out there) and
working to understand what you have there already, so that you can both brief
your consultant accurately and assess what candidates say about the task. it's
just possible you'll suddenly spot what's needed, but unless you have a good
palette of understanding and techniques, there are risks to your live data.

From the screenshot, your database looks "custom-made". That one form is doing
a whole raft of things - and that's not quite the approach you evolve when
working with "normalised" data, where you get into the habit of keeping things
separate and independent, while linked. I think a 50-week-a-year developer
would have come up with much cleaner look, so you might have some over-complex
code and techniques under the hood.

Were this a few years ago (or conceivably 18 months ahead from now) I might
offer to take it on, but I really can't take anything on at the moment. So I
hope the above is of some help, and I wish you the best of luck.

--

Phil, London

On Sun, 14 Aug 2022 13:44:11 +0100, Philip Herlihy
<PhillipHerlihy@SlashDevNull.invalid> wrote:

>In article <h00efhl398msu722ginru8qh6lsgagbqbq@4ax.com>, Peter Jason wrote...
>>
>> On Fri, 12 Aug 2022 10:37:28 +0100, Philip Herlihy
>> <PhillipHerlihy@SlashDevNull.invalid> wrote:
>>
>> >In article <r82cfh1qqukd7mg22itt08hukphv999kaq@4ax.com>, Peter Jason wrote...
>> >>
>> >> In tables design view I have a short text field that I want in Red
>> >> Bold.
>> >>
>> >> Where is the formatting code to put the Red Bold?
>> >> Is there an extensive list of other format codes?
>> >>
>> >> Peter
>> >
>> >It's become conventional to have a separation between raw data and display
>> >considerations. In modern web design a page is structured with HMTL (shunning
>> >legacy formatting features) with presentation controlled using CSS (Cascading
>> >Style Sheets). Similarly in Access, the table design view has no presentation
>> >formatting other than that which controls the way numerics are to be shown:
>> >percentage, currency, date (stored as a number) and so on. If you wanted to
>> >associate in your data a colour with, say, a type of grocery item, you'd need a
>> >table with the class of item and a colour value.
>> >
>> >But that would be an unusual thing to do in Access, which provides forms and
>> >reports to handle presentation, and it's actually rare to expect users to
>> >interact with data tables directly. You can base a form or a report on a
>> >table, or from a query which can select desired rows and columns from one or
>> >more tables. It's easier to do than many think, and if you don't like the
>> >result, you can safely delete the form or report leaving your underlying data
>> >unchanged. There are wizards, and lots of good videos on YouTube. Typically,
>> >you can get something you're surprisingly pleased with up in a few minutes, and
>> >then you spend the rest of your life turning it into a work of art... (ask me
>> >how I know.)
>>
>> Thanks, I've always used Access from Access97, and sometimes I can get
>> some colloguing in the fields. In the screen below I have done this.
>> Trouble is I depend nearly always on the Wizards, but have been known
>> to use cut/paste VBA code. I have been stumped by the 3-level Bill of
>> Materials (BOM) a consultant installed for me ages ago (now he's
>> disappeared). Do you know of an Access equivalent 3-level BOM
>> template?
>> https://postimg.cc/Y4b57Krz
>
>I'm afraid I don't.
>
>I looked at your screenshot, and yes, that's a form, not a table - you can
>certainly make forms colourful (etc.).

>
>Access is certainly very powerful, and it's hard to imagine how to build an

>application like yours without an underlying database. For custom applications
>for small-to-medium businesses, Access is marvellous.

It does have an underlying database.
https://postimg.cc/WFFHxB75that has grown over a long time.
>
>But it needs "safe hands". An ill-constructed database can mangle your data so
>comprehensively that it might as well be encrypted. If you need to rely on
>that data, then you need to invest in your database - just as if you rely on a
>vehicle for deliveries to customers, it's best to get it serviced by someone
>who really knows what they are doing, and maybe to plan for its replacement in
>time.

>
>So keeping your system going is going to need you to go in one of two
>directions - either you skill yourself up to a level when you're writing things
>rather than copying them, or hiring someone to do the work for you. I'm an
>Access developer (retired, and now quite rusty) and the going rate for such
>work is not trivial - it's intricate work demanding evolved skills. In Usenet
>(here!) there used to be several groups where real experts hung out and were
>prepared to share their understanding. But this group seems to be all that
>remains, and this one is pretty quiet. I have to say I don't know where you'd
>go to link up with expert advice - though I guess there must be somewhere! The
>web-based forums I've seen do have a much reduced signal-to-noise ratio, and
>official "support" forums seem staffed by clueless interns whose principal
>concern appears to be excruciating over-politeness.
>
>There are books, and the former Lynda.com videos (now on LinkedIn) are very
>good indeed. Access is huge fun to learn and master, but the more you master
>it the more you become aware of possible errors you may have made in the past.
>Get your table design right ("normalised") and the battle's half-won. It is
>impossible to over-emphasise that point - a bad table design means you're
>condemned to work around it.
>
>One real problem with custom code is that it isn't always (often?) well-
>documented, and it can be hard to figure out how it's supposed to work.
>Sometimes it can feel (and even be) easier to scrap an existing version and
>start again. As a trained software engineer, I once delivered a one-line
>shell-script with two full A4 pages of explanatory text; my successor was
>eventually effusively grateful! Access doesn't particularly lend itself either
>to prompting developers to document it, or to reverse-engineering.
>
>It's hard to know what useful advice to offer. I'd encourage you to continue
>to build your skills in Access - you clearly have what it takes, though you may
>need to invest time in working systematically towards mastery. I'd figure you
>probably need another consultant to fix your BOM functionality, and (in keeping
>with the importance to your business) that won't be cheap. Unless it's really
>urgent, I'd spend some time simultaneously building your skills (those LinkedIn
>courses are good, and there are other online training providers out there) and
>working to understand what you have there already, so that you can both brief
>your consultant accurately and assess what candidates say about the task. it's
>just possible you'll suddenly spot what's needed, but unless you have a good
>palette of understanding and techniques, there are risks to your live data.
>
>From the screenshot, your database looks "custom-made". That one form is doing
>a whole raft of things - and that's not quite the approach you evolve when
>working with "normalised" data, where you get into the habit of keeping things
>separate and independent, while linked. I think a 50-week-a-year developer
>would have come up with much cleaner look, so you might have some over-complex
>code and techniques under the hood.
>
>Were this a few years ago (or conceivably 18 months ahead from now) I might
>offer to take it on, but I really can't take anything on at the moment. So I
>hope the above is of some help, and I wish you the best of luck.

I'm overhauling the BOM, by deleting obsolete customers and products,
and the relationships between.
Also by re-entering some formulas.