Showing posts with label pro. Show all posts
Showing posts with label pro. Show all posts

Friday, March 30, 2012

Migrating from Developer Edition to Standard Edition

Hello,
I have Reporting Sevices Developer Edition running on a Windows XP Pro
workstation. I want to migrate it to Reporting Services/SQL Server Standard
Edition on a Windows 2003 server. Can this be done? Since the edition of RS
changes, and the edition of SQL Server changes, and the hardware changes, I
need to know if this is feasible, or if it would be better to redeploy the
reports to the new server. BOL isn't very helpful in this area, and I don't
have time to learn C# to use the RS utility.
Thanks in advance.Given that it is so easy to redeploy and the fact that everything is
changing, my advice is to install new and then redeploy.
Bruce L-C
"Cable Guy" <Cable Guy@.discussions.microsoft.com> wrote in message
news:DCD83C56-B311-45EB-90A6-1A5F45B5A87B@.microsoft.com...
> Hello,
> I have Reporting Sevices Developer Edition running on a Windows XP Pro
> workstation. I want to migrate it to Reporting Services/SQL Server
Standard
> Edition on a Windows 2003 server. Can this be done? Since the edition of
RS
> changes, and the edition of SQL Server changes, and the hardware changes,
I
> need to know if this is feasible, or if it would be better to redeploy the
> reports to the new server. BOL isn't very helpful in this area, and I
don't
> have time to learn C# to use the RS utility.
> Thanks in advance.|||Others would need to jump in for your answer. I can't really help you with
that.
Bruce L-C
"Cable Guy" <CableGuy@.discussions.microsoft.com> wrote in message
news:40C1D674-60C1-49AB-B8B6-5483EE8BDE2F@.microsoft.com...
> Hi Bruce,
> Thanks for the reply. That is what I was initially persuaded to do, but
> redeploying introduces the possibility of something being overlooked, and
> that is what we want to avoid. Is it possible to use the RS utility to do
> what we need it to do (i.e. copy the logical contents of the database to a
> new database/server/edition) and have it work properly? Do you know of
> any
> good documentation on the RS utility?
> "Bruce Loehle-Conger" wrote:
>> Given that it is so easy to redeploy and the fact that everything is
>> changing, my advice is to install new and then redeploy.
>> Bruce L-C
>> "Cable Guy" <Cable Guy@.discussions.microsoft.com> wrote in message
>> news:DCD83C56-B311-45EB-90A6-1A5F45B5A87B@.microsoft.com...
>> > Hello,
>> >
>> > I have Reporting Sevices Developer Edition running on a Windows XP Pro
>> > workstation. I want to migrate it to Reporting Services/SQL Server
>> Standard
>> > Edition on a Windows 2003 server. Can this be done? Since the edition
>> > of
>> RS
>> > changes, and the edition of SQL Server changes, and the hardware
>> > changes,
>> I
>> > need to know if this is feasible, or if it would be better to redeploy
>> > the
>> > reports to the new server. BOL isn't very helpful in this area, and I
>> don't
>> > have time to learn C# to use the RS utility.
>> >
>> > Thanks in advance.
>>|||Hi Bruce,
Thanks for the reply. That is what I was initially persuaded to do, but
redeploying introduces the possibility of something being overlooked, and
that is what we want to avoid. Is it possible to use the RS utility to do
what we need it to do (i.e. copy the logical contents of the database to a
new database/server/edition) and have it work properly? Do you know of any
good documentation on the RS utility?
"Bruce Loehle-Conger" wrote:
> Given that it is so easy to redeploy and the fact that everything is
> changing, my advice is to install new and then redeploy.
> Bruce L-C
> "Cable Guy" <Cable Guy@.discussions.microsoft.com> wrote in message
> news:DCD83C56-B311-45EB-90A6-1A5F45B5A87B@.microsoft.com...
> > Hello,
> >
> > I have Reporting Sevices Developer Edition running on a Windows XP Pro
> > workstation. I want to migrate it to Reporting Services/SQL Server
> Standard
> > Edition on a Windows 2003 server. Can this be done? Since the edition of
> RS
> > changes, and the edition of SQL Server changes, and the hardware changes,
> I
> > need to know if this is feasible, or if it would be better to redeploy the
> > reports to the new server. BOL isn't very helpful in this area, and I
> don't
> > have time to learn C# to use the RS utility.
> >
> > Thanks in advance.
>
>sql

Wednesday, March 7, 2012

Microsoft Windows 2000 alocation unit

Hi,
In <<SQL Server 2000 Operations Guide: Capacity and Storage Management>>
(http://www.microsoft.com/technet/pro...n/sqlops6.mspx)
in section <<Windows NT File System (NTFS) Allocation Unit>> I read the
following:
<<The best practice for SQL Server is to choose 64 KB, because this reduces
the likelihood of I/Os that span distinct NTFS allocations, which then might
result in split I/Os.>>
How many of you have chosen the 64K allocation unit size? Did you get any
noticeable performance gains? How much worse is the default 4KB size than
64KB, when the data disk is, say, RAID10 with 128KB stripe size?
Many thanks,
Oskar
In addition to my previous post: does the bigger allocation unit size really
make sense for the disk, on which you place the tempdb database?
"Oskar" wrote:

> Hi,
> In <<SQL Server 2000 Operations Guide: Capacity and Storage Management>>
> (http://www.microsoft.com/technet/pro...n/sqlops6.mspx)
> in section <<Windows NT File System (NTFS) Allocation Unit>> I read the
> following:
> <<The best practice for SQL Server is to choose 64 KB, because this reduces
> the likelihood of I/Os that span distinct NTFS allocations, which then might
> result in split I/Os.>>
> How many of you have chosen the 64K allocation unit size? Did you get any
> noticeable performance gains? How much worse is the default 4KB size than
> 64KB, when the data disk is, say, RAID10 with 128KB stripe size?
> --
> Many thanks,
> Oskar
>

Friday, February 24, 2012

Microsoft Update & SP1

Hi,
I recently upgraded to SQL Server 2005 SP1 (developer edition) on WinXP Pro
+ SP2 by using the Microsoft Update service.
No issues were noted during the upgrade process, and EXEC master..xp_msver
returns 9.00.2047.00 in the ProductVersion column.
However, subsequent running of Microsoft Update still shows SQL Server 2005
SP1 (KB913090) as needing to be installed.
Is this a bug with Microsoft Update, or does it mean that SP1 isn't
installed properly?
Any assistance gratefully received.
MarkHi Mark
It looks like you are on SP1 on that instance! Do you have multiple
instances on this machine? Did you check the installation's log files
(hopefully this is going to be in the same place as a manual installation!).
Have you rebooted since the upgrade?
If you are confident that it is upgraded then you could choose the option to
not show the update again when the update details are expanded.
John
"Mark Rae" wrote:

> Hi,
> I recently upgraded to SQL Server 2005 SP1 (developer edition) on WinXP Pr
o
> + SP2 by using the Microsoft Update service.
> No issues were noted during the upgrade process, and EXEC master..xp_msver
> returns 9.00.2047.00 in the ProductVersion column.
> However, subsequent running of Microsoft Update still shows SQL Server 200
5
> SP1 (KB913090) as needing to be installed.
> Is this a bug with Microsoft Update, or does it mean that SP1 isn't
> installed properly?
> Any assistance gratefully received.
> Mark
>
>|||"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:34B375F1-9334-4141-B282-2FB06C8D4A44@.microsoft.com...

> Do you have multiple instances on this machine?
No.

> Did you check the installation's log files (hopefully this is going to be
> in the same place as a manual installation!).
Yes.

> Have you rebooted since the upgrade?
Yes. And reapplied the upgrade. And rebooted after that.

> If you are confident that it is upgraded
I'm as confident as I can be, I suppose. Other than master..xp_msver /
SELECT @.@.VERSION, is there anything else I can try...?

> then you could choose the option to not show the update again
> when the update details are expanded.
Yes, but I was loathe to do that until I'd at least asked in here. I've done
a Google search, and there doesn't seem to be anything about this specific
issue. Lots about SP1, of course, but nothing relating to problems with
applying it through Microsoft Update.
I should receive SP1 on DVD any day now as part of my MSDN Universal
subscription, so I'll reinstall it from that and then remove the option from
Microsoft Update if that doesn't fix it.

Microsoft Update & SP1

Hi,
I recently upgraded to SQL Server 2005 SP1 (developer edition) on WinXP Pro
+ SP2 by using the Microsoft Update service.
No issues were noted during the upgrade process, and EXEC master..xp_msver
returns 9.00.2047.00 in the ProductVersion column.
However, subsequent running of Microsoft Update still shows SQL Server 2005
SP1 (KB913090) as needing to be installed.
Is this a bug with Microsoft Update, or does it mean that SP1 isn't
installed properly?
Any assistance gratefully received.
MarkHi Mark
It looks like you are on SP1 on that instance! Do you have multiple
instances on this machine? Did you check the installation's log files
(hopefully this is going to be in the same place as a manual installation!).
Have you rebooted since the upgrade?
If you are confident that it is upgraded then you could choose the option to
not show the update again when the update details are expanded.
John
"Mark Rae" wrote:
> Hi,
> I recently upgraded to SQL Server 2005 SP1 (developer edition) on WinXP Pro
> + SP2 by using the Microsoft Update service.
> No issues were noted during the upgrade process, and EXEC master..xp_msver
> returns 9.00.2047.00 in the ProductVersion column.
> However, subsequent running of Microsoft Update still shows SQL Server 2005
> SP1 (KB913090) as needing to be installed.
> Is this a bug with Microsoft Update, or does it mean that SP1 isn't
> installed properly?
> Any assistance gratefully received.
> Mark
>
>|||"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:34B375F1-9334-4141-B282-2FB06C8D4A44@.microsoft.com...
> Do you have multiple instances on this machine?
No.
> Did you check the installation's log files (hopefully this is going to be
> in the same place as a manual installation!).
Yes.
> Have you rebooted since the upgrade?
Yes. And reapplied the upgrade. And rebooted after that.
> If you are confident that it is upgraded
I'm as confident as I can be, I suppose. Other than master..xp_msver /
SELECT @.@.VERSION, is there anything else I can try...?
> then you could choose the option to not show the update again
> when the update details are expanded.
Yes, but I was loathe to do that until I'd at least asked in here. I've done
a Google search, and there doesn't seem to be anything about this specific
issue. Lots about SP1, of course, but nothing relating to problems with
applying it through Microsoft Update.
I should receive SP1 on DVD any day now as part of my MSDN Universal
subscription, so I'll reinstall it from that and then remove the option from
Microsoft Update if that doesn't fix it.

Monday, February 20, 2012

Microsoft SQL Server Migration Assistant for Access Fails to Migrate Data

I attempted to use SSMA to migrate a 2000 file format .mdb into SQL Server Express (and, as I've just purchased VS2005 Pro, into SQL Server Developer Edition).

The file is actually a backend, so nothing to migrate other than tables.

After several runs during which I received (and fixed up) some errors, the process runs smoothly with no errors or warnings, until it comes to the last step; migrating the data itself.

Data migration into 'parent' tables works fine. However, wherever I have data in a table with a foreign key relationship to any of the aforementioned 'parent' tables, it refuses to migrate it. The text of the error message will be very smiliar to the following (from the log):

[Datamigrator: Error] [464/7] [2007-09-23 14:18:54]: Exception: The INSERT statement conflicted with the FOREIGN KEY constraint "Branch$CompanyBranch". The conflict occurred in database "DPMTest", table "dbo.Company", column 'CompanyID'.

There is nothing wrong, so far as I can determine, with the relationships involved.

I can insert data into the tables using any of the following methods:

1. Directly in Access, in the source backend.

2. Using the original Access frontend application, attached to the source backend.

3. Using VB.Net forms I am developing, in the 'upsized' database.

4. Directly in the Management Studio, in the 'upsized' database.

None of these four methods complains in the least about the relationships which SSMA balks at.

I would be grateful for any ideas....thanks.

The error is self explanatory...

You are inserting companyID that are not there in the master table. Just run a select some thing like this

Select *from ThisTableName where CompanyID not In (select companyID from ParentComapnyTableName)

You will get few rows. this needs to be deleted otherwise you have to correct the data.

Madhu

|||

As I said, I can insert data via all other methods. I am not inserting CompanyID where it does not exist in the master table. There is only one CompanyID at this point, whose ID is '1'. If I add a Branch with CompanyID of '1' in the Access source database which, again, doesn't complain about the relationship - because there is no problem with the relationship, or the data I'm inserting - the Migration Assistant throws the abovementioned error.

I appreciate your response, but I feel you didn't comprehend my original post. Thanks, anyway.

|||I have "successfully" migrated MDB files only to find out that SQL and Visual Studio balks at them. Problems with constraints, views, and other stuff.

Microsoft SQL Server Migration Assistant for Access Fails to Migrate Data

I attempted to use SSMA to migrate a 2000 file format .mdb into SQL Server Express (and, as I've just purchased VS2005 Pro, into SQL Server Developer Edition).

The file is actually a backend, so nothing to migrate other than tables.

After several runs during which I received (and fixed up) some errors, the process runs smoothly with no errors or warnings, until it comes to the last step; migrating the data itself.

Data migration into 'parent' tables works fine. However, wherever I have data in a table with a foreign key relationship to any of the aforementioned 'parent' tables, it refuses to migrate it. The text of the error message will be very smiliar to the following (from the log):

[Datamigrator: Error] [464/7] [2007-09-23 14:18:54]: Exception: The INSERT statement conflicted with the FOREIGN KEY constraint "Branch$CompanyBranch". The conflict occurred in database "DPMTest", table "dbo.Company", column 'CompanyID'.

There is nothing wrong, so far as I can determine, with the relationships involved.

I can insert data into the tables using any of the following methods:

1. Directly in Access, in the source backend.

2. Using the original Access frontend application, attached to the source backend.

3. Using VB.Net forms I am developing, in the 'upsized' database.

4. Directly in the Management Studio, in the 'upsized' database.

None of these four methods complains in the least about the relationships which SSMA balks at.

I would be grateful for any ideas....thanks.

The error is self explanatory...

You are inserting companyID that are not there in the master table. Just run a select some thing like this

Select *from ThisTableName where CompanyID not In (select companyID from ParentComapnyTableName)

You will get few rows. this needs to be deleted otherwise you have to correct the data.

Madhu

|||

As I said, I can insert data via all other methods. I am not inserting CompanyID where it does not exist in the master table. There is only one CompanyID at this point, whose ID is '1'. If I add a Branch with CompanyID of '1' in the Access source database which, again, doesn't complain about the relationship - because there is no problem with the relationship, or the data I'm inserting - the Migration Assistant throws the abovementioned error.

I appreciate your response, but I feel you didn't comprehend my original post. Thanks, anyway.

|||I have "successfully" migrated MDB files only to find out that SQL and Visual Studio balks at them. Problems with constraints, views, and other stuff.