This is my first Access project to develop, so I'm learning the ropes of
dealing with SQL Server. One thing that cropped up is that the fields seems
to be filled with training blanks. On forms that's only "strange" and an
inconvenience, but on reports it can force extra rows for "can grow" fields.
I solved the problem by doing an rtrim() on all the fields in a query before
using them in forms and reports. Is that a known issue and is there a
better/easier way to handle it?

Thanks,

Mick Ruthven

Mick

I suspect you are running into an issue with the data type in SQL Server.
If the data field/column were defined with "varchar" (variable length,
character type), you shouldn't be seeing trailing blanks.

You might find that the data fields are defined as char (character), with a
fixed length, as in char(30).

--
Regards

Jeff Boyce
<Office/Access MVP>

"Mick Ruthven" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> This is my first Access project to develop, so I'm learning the ropes of
> dealing with SQL Server. One thing that cropped up is that the fields
seems
> to be filled with training blanks. On forms that's only "strange" and an
> inconvenience, but on reports it can force extra rows for "can grow"
fields.
> I solved the problem by doing an rtrim() on all the fields in a query
before
> using them in forms and reports. Is that a known issue and is there a
> better/easier way to handle it?
>
> Thanks,
>
> Mick Ruthven
>
>

Bingo! The offending fields are char, not varchar. Is there any reason to
not make all non-numeric fields varchar? Any drawbacks?

"Jeff Boyce" <(E-Mail Removed)-DISCARD_HYPHEN_TO_END> wrote in message
news:(E-Mail Removed)...
> Mick
>
> I suspect you are running into an issue with the data type in SQL Server.
> If the data field/column were defined with "varchar" (variable length,
> character type), you shouldn't be seeing trailing blanks.
>
> You might find that the data fields are defined as char (character), with
a
> fixed length, as in char(30).
>
> --
> Regards
>
> Jeff Boyce
> <Office/Access MVP>
>
> "Mick Ruthven" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > This is my first Access project to develop, so I'm learning the ropes of
> > dealing with SQL Server. One thing that cropped up is that the fields
> seems
> > to be filled with training blanks. On forms that's only "strange" and an
> > inconvenience, but on reports it can force extra rows for "can grow"
> fields.
> > I solved the problem by doing an rtrim() on all the fields in a query
> before
> > using them in forms and reports. Is that a known issue and is there a
> > better/easier way to handle it?
> >
> > Thanks,
> >
> > Mick Ruthven
> >
> >
>

I don't see any, but then I'm not a SQL-Server guru. You may want to check
in one of the SQL-related newsgroups.

--
Regards

Jeff Boyce
<Office/Access MVP>

"Mick Ruthven" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Bingo! The offending fields are char, not varchar. Is there any reason to
> not make all non-numeric fields varchar? Any drawbacks?
>
> "Jeff Boyce" <(E-Mail Removed)-DISCARD_HYPHEN_TO_END> wrote in message
> news:(E-Mail Removed)...
> > Mick
> >
> > I suspect you are running into an issue with the data type in SQL
Server.
> > If the data field/column were defined with "varchar" (variable length,
> > character type), you shouldn't be seeing trailing blanks.
> >
> > You might find that the data fields are defined as char (character),
with
> a
> > fixed length, as in char(30).
> >
> > --
> > Regards
> >
> > Jeff Boyce
> > <Office/Access MVP>
> >
> > "Mick Ruthven" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > This is my first Access project to develop, so I'm learning the ropes
of
> > > dealing with SQL Server. One thing that cropped up is that the fields
> > seems
> > > to be filled with training blanks. On forms that's only "strange" and
an
> > > inconvenience, but on reports it can force extra rows for "can grow"
> > fields.
> > > I solved the problem by doing an rtrim() on all the fields in a query
> > before
> > > using them in forms and reports. Is that a known issue and is there a
> > > better/easier way to handle it?
> > >
> > > Thanks,
> > >
> > > Mick Ruthven
> > >
> > >
> >
>
>

Thanks for your help, Jeff! I just discovered the
microsoft.public.access.adp.sqlserver newsgrop which seems like the one to
be asking my Access Project questions in.

"Jeff Boyce" <(E-Mail Removed)-DISCARD_HYPHEN_TO_END> wrote in message
news:(E-Mail Removed)...
> I don't see any, but then I'm not a SQL-Server guru. You may want to
check
> in one of the SQL-related newsgroups.
>
> --
> Regards
>
> Jeff Boyce
> <Office/Access MVP>