Access Report/Import Groupings

Hi Folks
Importing Access reports that have grouping are really quite a struggle.
All of the grouping sections are imported as controlled by report parameters.
Am I missing something, this is incredibly painfull with all of the build
errors in VS.NET?
RobI've reported this earlier, but the importation truely 'mangles' Access
Reports that are based on SQL Server sprocs that dynamically create record
sets (in my case dynamic creation of fields related to creating pivot tables
on the fly).
The issue is 'what does SSRS feel that it's important to do' in order to
retrieve a record set associated with a report.
The way to get ALL of this to work is a 3 step process:
1. Import the report from Access, which will give you a working sproc
dataset, but a mangle report import (that contains all kind of parameterized
stuff that SSRS couldn't figure out how to map).
2. Run the sproc standalone (in either Access or SQL Server) and create a
'working table' from the result set. Next, remap your Access query to this
'hard coded' table.
3. Finally, rerun the import on the remapped Access Report. The import is
almost correct (things like page breaks have to be redone and some other
little anomolies).
Delete the second dataset associated with 2nd import and delete the 1st
.rdl. This leaves you with a good dataset from the 1st import and a good
report from the 2nd import. Now just remap the dataset for the .rdl.
This is all because SSRS gets a little TOO carried away with trying to
interpret calls to sprocs (which use things like #tables and dynamically
define columns). This needs to be changed in the report creation and import
features of the product. This is TOO constraining to the point where the
product is making poor import decisions as well as being an absolute 'show
stopper' on new report creation where it uses a sproc.
Rob
"tutor" wrote:
> Hi Folks
> Importing Access reports that have grouping are really quite a struggle.
> All of the grouping sections are imported as controlled by report parameters.
> Am I missing something, this is incredibly painfull with all of the build
> errors in VS.NET?
> Rob

Access Memo field to SQL Server Text field

Hi,

I'm importing an Access database to SQL Server 2000.
The issue I ran into is pretty frustrating... All Memo fields that get copied over (as Text fields) appear to be fine and visible in SQL Server Enterprise Manager... except when I display them on the web via ASP - everything is blank (no content at all).

I didn't have that problem with Access, so I ruled out the possibility that there's something wrong with the original data.

Is this some sort of an encoding problem that arose during database import?
I would appreciate any pointers.If the data is visible within SQL Server, but not from your ASP page, then the problem is with your ASP page and the way it is pulling the text data.
Do you really need this to be a text field? The varchar datatype will handle up to 8000 bytes.|||That's a good point - I might be able to get away with varchar. It's something I'll look into, but I'm still curious as to why the data behaves this way (I ran into similar problems in the past while trying to import Access data to SQL server).

My ASP page is functioning properly. I use a simple "SELECT *" statement to pull the data and display it on the page. With an Access DSN it encounters no problems and shows all the data as intended. When I import the data into SQL Server and swap the DSN to point to the newly-created database (while not modifying the ASP page itself in any way) the text fields display no content.|||A text field in SQL Server is not stored within the record. The record actually only stores a pointer to the location of the actual data. This may be why your page is not handling it properly, but I don't know the work-around. You could try posting your question on the ASP forum.|||Interesting... I was aware that Text fields are stored differently and separately from the regular data in the database, but I didn't think it would affect the way they're displayed through the recordset...

Maybe there's something that can be done on the ASP side - I'll ask some ASP guys.

Thanks.|||Interesting... I was aware that Text fields are stored differently and separately from the regular data in the database, but I didn't think it would affect the way they're displayed through the recordset...I wouldn't have thought so either, but it is my best guess.
What happens in your ASP code if you enumerate the column names rather than using "select *" (which is a bad practice anyway)?|||I use a simple "SELECT *" statement to pull the data and display it on the page.

ahhhhhhhhhhhhhhhhhhhhhhhhhhh

http://weblogs.sqlteam.com/brettk/archive/2004/04/22/1272.aspx|||I try to do it properly with larger systems and database, but, yeah, for me it's laziness that makes me use "Select *"...|||I try to do it properly with larger systems and database, but, yeah, for me it's laziness that makes me use "Select *"...

Hey! No one's lazier than me....

SELECT ', ' + COLUMN_NAME FROM INFORMATION_SCHEMA.Columns
WHERE TABLE_NAME = 'xxx'
ORDER BY ORDINAL_POSITION

SELECT * can buy you a boatload of trouble...so it's amatter how you want to spend your laziness...you have no choice when you have exploding code|||I wouldn't have thought so either, but it is my best guess.
What happens in your ASP code if you enumerate the column names rather than using "select *" (which is a bad practice anyway)?

Well, that's an interesting question, mostly because it gives me some sort of a deja vu feeling - as if I encountered something like this several years ago...
It's possible that I did something like this in the past and fixed the problem that way.
I'll check into this on Thursday when I'm back at work.

Thanks.|||You are off UNTIL Thursday?

Okay, but this Thursday is Turkey Day for us Yanks, so you'll have to depend upon the Pootle Flumps and Cannucks of the world to help you out.|||Hey! No one's lazier than me....

SELECT ', ' + COLUMN_NAME FROM INFORMATION_SCHEMA.Columns
WHERE TABLE_NAME = 'xxx'
ORDER BY ORDINAL_POSITION

SELECT * can buy you a boatload of trouble...so it's amatter how you want to spend your laziness...you have no choice when you have exploding code

That's an interesting way to structure a query - I've never done it this way before.

Dare to dream... Sorry, you think that you're the laziness champ, but you're not. Your laziness doesn't compare to mine - not even close.|||You are off UNTIL Thursday?

Okay, but this Thursday is Turkey Day for us Yanks, so you'll have to depend upon the Pootle Flumps and Cannucks of the world to help you out.

Yes, it sounds a bit odd. I'm actually at work as we speak, but I also have another part time job as a contractor with my previous employer. Thanksgiving will be a good time to come in and get a bunch of work out of the way.|||See but here's the rub, my laziness is born out of economy of effort..the smarter you work, the less you have to

some laziness makes your life more simple, other types make your life much more difficult, you have to decide|||See but here's the rub, my laziness is born out of economy of effort..the smarter you work, the less you have to

some laziness makes your life more simple, other types make your life much more difficult, you have to decide

Agree. Mine usually gets me in trouble somewhere down the line.

... but it still feels good to be the "Champ" :)