Subreports and SQL

Hi,

Can someone tell me if there is any known difficulty between subreports and
SQL. I saw a post on this board (can't remember where but I saw it) about
difficulties with having subforms in an Access database and then migrating
the db to an SQL platform. Apparently the subforms don't translate well...
Anyway, I need to know if this is true for subreports also. I teach Access in
an environment where people use Access for databases serving 8 people. If
more people use the db it gets migrated to SQL, so I don't want to teach a
concept that they should avoid in the event their database does get moved
over.

Thanks for the help.
Gillian

Gillian

Terminology...

Subreports and subforms are not the same.

This is a tables-oriented newsgroup, relevant to neither forms nor reports.

You "migrate" data (i.e., tables) to SQL-Server (or other back-ends), but
forms and reports (and their subs-) don't migrate.

Access (front-end) is a VERY useful way to build user interfaces (i.e.,
forms, reports), regardless of the back-end that stores the data.

I'm not clear on what you are asking about...

--
More info, please ...

Jeff Boyce
Access MVP

"GillianHG" wrote in message
news
Hi,

Can someone tell me if there is any known difficulty between subreports
and
SQL. I saw a post on this board (can't remember where but I saw it) about
difficulties with having subforms in an Access database and then migrating
the db to an SQL platform. Apparently the subforms don't translate well...
Anyway, I need to know if this is true for subreports also. I teach Access
in
an environment where people use Access for databases serving 8 people. If
more people use the db it gets migrated to SQL, so I don't want to teach a
concept that they should avoid in the event their database does get moved
over.

Thanks for the help.
Gillian

Hi Jeff, sorry, I will try to be more clear.

I have heard that when database tables are migrated to SQL (but still
continuing to use Access as a front end for forms, reports, etc) that having
subforms on your forms will impact functionality. My question is will
subreports have the same effect? Is the problem with 'subs' (subforms,
subreports) on objects or just with subforms?

I posted this in the design area because to me it is a design question. I
don't want to tell my users to build something that won't work if/when their
tables are migrated to SQL. If I should be posting elsewhere then I will do
that, no problem.

I appreciate your help,
Gillian
"Jeff Boyce" wrote:

Gillian

Terminology...

Subreports and subforms are not the same.

This is a tables-oriented newsgroup, relevant to neither forms nor reports.

You "migrate" data (i.e., tables) to SQL-Server (or other back-ends), but
forms and reports (and their subs-) don't migrate.

Access (front-end) is a VERY useful way to build user interfaces (i.e.,
forms, reports), regardless of the back-end that stores the data.

I'm not clear on what you are asking about...

--
More info, please ...

Jeff Boyce
Access MVP

"GillianHG" wrote in message
news
Hi,

Can someone tell me if there is any known difficulty between subreports
and
SQL. I saw a post on this board (can't remember where but I saw it) about
difficulties with having subforms in an Access database and then migrating
the db to an SQL platform. Apparently the subforms don't translate well...
Anyway, I need to know if this is true for subreports also. I teach Access
in
an environment where people use Access for databases serving 8 people. If
more people use the db it gets migrated to SQL, so I don't want to teach a
concept that they should avoid in the event their database does get moved
over.

Thanks for the help.
Gillian

Gillian

No apologies necessary -- I just wanted to make sure we were both speaking
the same language.

I've migrated the data/back-end of Access apps from JET to SQL-Server and
maintained my main form/subform and main report/subreport structures. The
issues I encountered had more to do with modifying my queries and code to
better handle the new relationship (i.e., SQL-Server, not JET).

A small example -- Access/JET creates a new Autonumber (e.g., primary key
value) as soon as the (new) record is "dirtied". SQL-Server does NOT create
a new Identity (primary key) until AFTER the new record is saved.

--
Good luck

Jeff Boyce
Access MVP

"GillianHG" wrote in message
...
Hi Jeff, sorry, I will try to be more clear.

I have heard that when database tables are migrated to SQL (but still
continuing to use Access as a front end for forms, reports, etc) that
having
subforms on your forms will impact functionality. My question is will
subreports have the same effect? Is the problem with 'subs' (subforms,
subreports) on objects or just with subforms?

I posted this in the design area because to me it is a design question. I
don't want to tell my users to build something that won't work if/when
their
tables are migrated to SQL. If I should be posting elsewhere then I will
do
that, no problem.

I appreciate your help,
Gillian
"Jeff Boyce" wrote:

Gillian

Terminology...

Subreports and subforms are not the same.

This is a tables-oriented newsgroup, relevant to neither forms nor
reports.

You "migrate" data (i.e., tables) to SQL-Server (or other back-ends),
but
forms and reports (and their subs-) don't migrate.

Access (front-end) is a VERY useful way to build user interfaces (i.e.,
forms, reports), regardless of the back-end that stores the data.

I'm not clear on what you are asking about...

--
More info, please ...

Jeff Boyce
Access MVP

"GillianHG" wrote in message
news
Hi,

Can someone tell me if there is any known difficulty between
subreports
and
SQL. I saw a post on this board (can't remember where but I saw it)
about
difficulties with having subforms in an Access database and then
migrating
the db to an SQL platform. Apparently the subforms don't translate
well...
Anyway, I need to know if this is true for subreports also. I teach
Access
in
an environment where people use Access for databases serving 8
people. If
more people use the db it gets migrated to SQL, so I don't want to
teach a
concept that they should avoid in the event their database does get
moved
over.

Thanks for the help.
Gillian