One column missing from datasets even after refresh?

My report's data source is a stored procedure which takes 4 parameters. If I execute the sp from the data tab it returns the correct data and columns; but if I right click the Report Datasets from the Datasets view and click on refresh I'm always missing one column. Is this related to the way the sp was written? Anybody had same expericence before? Thanks!

I have.

One thing you can do is check for a matching .rdl.data file and blow that away, see if next data pull rewrites the cached data.

Another thing you can probably do is just add it in manually. Rightclick on the *name* of the dataset (underneath the Report DataSets node in the Datasets window) and choose "Add..."

>L<

|||

Thanks for the help! The first method doesn't work. Even if I add a new report from scratch, the available fields are missing that column if I put the sp in the query builder from report build wizard.

Rightclick on the name of the dataset and add the missing column works, but after I deploy the report and go view the report from brower, I got the following message:

An error has occurred during report processing.

Query execution failed for data set 'RegionalLevelByWeek'.

For more information about this error navigate to the report server on the local server machine, or enable remote errors

|||Hmm. I think the first method doesn't work if you have a (usually generated) schema file associated

with the data -- I'm not looking at reports right now, so I could be wrong) -- you might have to "refresh" that file as well.

On the second one, do you have to re-deploy the datasource to the server or something? (remember it's "don't overwrite datasources during deploy" by default) Same is true with default values of params -- given your situation as you put it in this message, that might well be involved.

Now that I look at what you're saying here though... As far as your current thing with the two SP's, you could just put a dummy column into the first result set, couldn't you? The important thing to remember is that there is going to be *one* set of columns associated with that report, never two, so if your proc can return differently based on a param you pretty much have to make them match.

I'm sorry I can't do a worked example right now, it's always *something* find-able though...

>L<

sql

Ole DB type

Is there a reason why Ole DB is missing interger data type? I am using Execute Sql task with Ole DB Connection Manager and cannot find Interger type. Any ideas?Nevermind. I was unfamiliar with the Ole db types for SSIS. Long = integer.

Old transaction log is reported as missing during recovery

I've done this at least 50 times without issue on various databases, but this
one just doesn't want to play nice.
So I have a SQLServer2K database setup. I've got a home-grown disaster
recovery process in place, so that transactions are taken from one server and
migrated to a backup server every hour. Once it's up and running, the
process is pretty flawless. However, getting it setup can be tricky.
1) Set the recovery model to "Full".
2) Backup your transaction logs
3) Do a full backup
4) Copy the backup to the backup server
5) Restore in to a read only database
Transaction logs can now be backed up on the source database, copied over
and applied to the backup server.
This isn't working this time though. No matter what I've tried, I still get
a message during the restore of the transaction logs such as the following:
"Executed as user: dbo. The log in this backup set begins at LSN
83111000001460600001, which is too late to apply to the database. An earlier
log backup that includes LSN 83075000002839600001 can be restored. [SQLSTATE
42000] (Error 4305) RESTORE LOG is terminating abnormally. [SQLSTATE 42000]
(Error 3013). The step failed."
Given the large gap between the two LSN #'s, I'm assuming that the database
thinks there is a very old transaction I'm missing. However, that is sheer
guesswork on my part.
The source box has been cycled, I've tried turning the recovery back and
forth between Full and Simple. This error is from my latest attempt, when I
swear I've done everything by the book.
Any suggestions of what might be causing this or where I should go from here?
Fred...
SQL lost a log somehow, I often had problems similar to this w/ home grown
log shipping.
Solution mostly relied upon: re-execute full backup, then restore & fire up
log shipping again. Full backup restores should be done nightly if
affordable...
Also - transactional replication ultimately proved the best solution for us,
transactions replicated within seconds, if we ever had to failover to backup,
I am much more confident minimal data would be lost as opposed to hourly log
restores...
Regards,
ChrisB
MCDBA OCP
www.MyDatabaseAdmin.com
"fkutz" wrote:

> I've done this at least 50 times without issue on various databases, but this
> one just doesn't want to play nice.
> So I have a SQLServer2K database setup. I've got a home-grown disaster
> recovery process in place, so that transactions are taken from one server and
> migrated to a backup server every hour. Once it's up and running, the
> process is pretty flawless. However, getting it setup can be tricky.
> 1) Set the recovery model to "Full".
> 2) Backup your transaction logs
> 3) Do a full backup
> 4) Copy the backup to the backup server
> 5) Restore in to a read only database
> Transaction logs can now be backed up on the source database, copied over
> and applied to the backup server.
> This isn't working this time though. No matter what I've tried, I still get
> a message during the restore of the transaction logs such as the following:
> "Executed as user: dbo. The log in this backup set begins at LSN
> 83111000001460600001, which is too late to apply to the database. An earlier
> log backup that includes LSN 83075000002839600001 can be restored. [SQLSTATE
> 42000] (Error 4305) RESTORE LOG is terminating abnormally. [SQLSTATE 42000]
> (Error 3013). The step failed."
> Given the large gap between the two LSN #'s, I'm assuming that the database
> thinks there is a very old transaction I'm missing. However, that is sheer
> guesswork on my part.
> The source box has been cycled, I've tried turning the recovery back and
> forth between Full and Simple. This error is from my latest attempt, when I
> swear I've done everything by the book.
> Any suggestions of what might be causing this or where I should go from here?
> Fred...