Your explanation makes SENSE and yes, it appears that I was checking
immediately after the change. (Bear in mind that I am still feeling my way
along.)
The indication that the records were DELETED is that Server Enterprise
Manager reports that the table has ZERO Rows. I had made the change in Data
Type in Server Enterprise Manager and then was making notes and documenting
what I had done. I went back to note the record count (which I had
previously found was conveniently reported in the Table Properties in Server
Enterprise Manager and it gave me the sensation that ALL of the data had
been deleted.
Now, I am thinking that it is doing precisely as you describe. I was able
to use the Import and Export Data tool to COPY all of the data from that
table to another table in a different database, which reports that it has
387,825 records (CORRECT). The original table STILL says in the Properties
that it has ZERO records, but that table has several Indices that are
probably being rebuilt.
But, the larger database from last night STILL SAYS that it has ZERO records
nine hours after the records appeared to all be deleted. But it has nine
million records and more than a few indices. And I am running this SQL
Evaulation on an older 866 MHz single processor system with only 512 Mbs of
memory.
Is there some way to monitor the things that SQL is doing in the BACKGROUND
to these tables?
"Jeff Dillon" <jeff@.removeemergencyreporting.com> wrote in message
news:ORaVrEcvEHA.2584@.TK2MSFTNGP10.phx.gbl...
> Of course you backed up your database, prior to making major changes to
> tables, correct?
> Whew..thank goodness.
> And no, generally records are not deleted. However, behind the scenes,
it's[vbcol=seagreen]
> probably renaming the table, creating a new structure, then inserting the
> records, then dropping and renaming the temp table.
> Did you check if the data was there immediately after changing the column
> datatype?
> Jeff
> "John Bishop" <ugradfrnd@.aol.com> wrote in message
> news:eDbrR9bvEHA.3896@.TK2MSFTNGP09.phx.gbl...
work[vbcol=seagreen]
> the
extract.[vbcol=seagreen]
> think).
> two
> Thereafter,
> datastructure
IS[vbcol=seagreen]
within[vbcol=seagreen]
> a
data
>
Run DBCC UPDATEUSAGE to correct the row count display in Enterprise Mangler.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"John Bishop" <ugradfrnd@.aol.com> wrote in message
news:%231Z4HYcvEHA.2016@.TK2MSFTNGP15.phx.gbl...
> Your explanation makes SENSE and yes, it appears that I was checking
> immediately after the change. (Bear in mind that I am still feeling my
way
> along.)
> The indication that the records were DELETED is that Server Enterprise
> Manager reports that the table has ZERO Rows. I had made the change in
Data
> Type in Server Enterprise Manager and then was making notes and
documenting
> what I had done. I went back to note the record count (which I had
> previously found was conveniently reported in the Table Properties in
Server
> Enterprise Manager and it gave me the sensation that ALL of the data had
> been deleted.
> Now, I am thinking that it is doing precisely as you describe. I was able
> to use the Import and Export Data tool to COPY all of the data from that
> table to another table in a different database, which reports that it has
> 387,825 records (CORRECT). The original table STILL says in the
Properties
> that it has ZERO records, but that table has several Indices that are
> probably being rebuilt.
> But, the larger database from last night STILL SAYS that it has ZERO
records
> nine hours after the records appeared to all be deleted. But it has nine
> million records and more than a few indices. And I am running this SQL
> Evaulation on an older 866 MHz single processor system with only 512 Mbs
of
> memory.
> Is there some way to monitor the things that SQL is doing in the
BACKGROUND[vbcol=seagreen]
> to these tables?
> "Jeff Dillon" <jeff@.removeemergencyreporting.com> wrote in message
> news:ORaVrEcvEHA.2584@.TK2MSFTNGP10.phx.gbl...
> it's
the[vbcol=seagreen]
column[vbcol=seagreen]
(Friday,[vbcol=seagreen]
> work
of[vbcol=seagreen]
> extract.
of
> IS
> within
> data
>
sql
Showing posts with label appears. Show all posts
Showing posts with label appears. Show all posts
Wednesday, March 21, 2012
Maybe the Records Are There After All
Your explanation makes SENSE and yes, it appears that I was checking
immediately after the change. (Bear in mind that I am still feeling my way
along.)
The indication that the records were DELETED is that Server Enterprise
Manager reports that the table has ZERO Rows. I had made the change in Data
Type in Server Enterprise Manager and then was making notes and documenting
what I had done. I went back to note the record count (which I had
previously found was conveniently reported in the Table Properties in Server
Enterprise Manager and it gave me the sensation that ALL of the data had
been deleted.
Now, I am thinking that it is doing precisely as you describe. I was able
to use the Import and Export Data tool to COPY all of the data from that
table to another table in a different database, which reports that it has
387,825 records (CORRECT). The original table STILL says in the Properties
that it has ZERO records, but that table has several Indices that are
probably being rebuilt.
But, the larger database from last night STILL SAYS that it has ZERO records
nine hours after the records appeared to all be deleted. But it has nine
million records and more than a few indices. And I am running this SQL
Evaulation on an older 866 MHz single processor system with only 512 Mbs of
memory.
Is there some way to monitor the things that SQL is doing in the BACKGROUND
to these tables?
"Jeff Dillon" <jeff@.removeemergencyreporting.com> wrote in message
news:ORaVrEcvEHA.2584@.TK2MSFTNGP10.phx.gbl...
> Of course you backed up your database, prior to making major changes to
> tables, correct?
> Whew..thank goodness.
> And no, generally records are not deleted. However, behind the scenes,
it's
> probably renaming the table, creating a new structure, then inserting the
> records, then dropping and renaming the temp table.
> Did you check if the data was there immediately after changing the column
> datatype?
> Jeff
> "John Bishop" <ugradfrnd@.aol.com> wrote in message
> news:eDbrR9bvEHA.3896@.TK2MSFTNGP09.phx.gbl...
work[vbcol=seagreen]
> the
extract.[vbcol=seagreen]
> think).
> two
> Thereafter,
> datastructure
IS[vbcol=seagreen]
within[vbcol=seagreen]
> a
data[vbcol=seagreen]
>Run DBCC UPDATEUSAGE to correct the row count display in Enterprise Mangler.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"John Bishop" <ugradfrnd@.aol.com> wrote in message
news:%231Z4HYcvEHA.2016@.TK2MSFTNGP15.phx.gbl...
> Your explanation makes SENSE and yes, it appears that I was checking
> immediately after the change. (Bear in mind that I am still feeling my
way
> along.)
> The indication that the records were DELETED is that Server Enterprise
> Manager reports that the table has ZERO Rows. I had made the change in
Data
> Type in Server Enterprise Manager and then was making notes and
documenting
> what I had done. I went back to note the record count (which I had
> previously found was conveniently reported in the Table Properties in
Server
> Enterprise Manager and it gave me the sensation that ALL of the data had
> been deleted.
> Now, I am thinking that it is doing precisely as you describe. I was able
> to use the Import and Export Data tool to COPY all of the data from that
> table to another table in a different database, which reports that it has
> 387,825 records (CORRECT). The original table STILL says in the
Properties
> that it has ZERO records, but that table has several Indices that are
> probably being rebuilt.
> But, the larger database from last night STILL SAYS that it has ZERO
records
> nine hours after the records appeared to all be deleted. But it has nine
> million records and more than a few indices. And I am running this SQL
> Evaulation on an older 866 MHz single processor system with only 512 Mbs
of
> memory.
> Is there some way to monitor the things that SQL is doing in the
BACKGROUND
> to these tables?
> "Jeff Dillon" <jeff@.removeemergencyreporting.com> wrote in message
> news:ORaVrEcvEHA.2584@.TK2MSFTNGP10.phx.gbl...
> it's
the[vbcol=seagreen]
column[vbcol=seagreen]
(Friday,[vbcol=seagreen]
> work
of[vbcol=seagreen]
> extract.
of[vbcol=seagreen]
> IS
> within
> data
>
immediately after the change. (Bear in mind that I am still feeling my way
along.)
The indication that the records were DELETED is that Server Enterprise
Manager reports that the table has ZERO Rows. I had made the change in Data
Type in Server Enterprise Manager and then was making notes and documenting
what I had done. I went back to note the record count (which I had
previously found was conveniently reported in the Table Properties in Server
Enterprise Manager and it gave me the sensation that ALL of the data had
been deleted.
Now, I am thinking that it is doing precisely as you describe. I was able
to use the Import and Export Data tool to COPY all of the data from that
table to another table in a different database, which reports that it has
387,825 records (CORRECT). The original table STILL says in the Properties
that it has ZERO records, but that table has several Indices that are
probably being rebuilt.
But, the larger database from last night STILL SAYS that it has ZERO records
nine hours after the records appeared to all be deleted. But it has nine
million records and more than a few indices. And I am running this SQL
Evaulation on an older 866 MHz single processor system with only 512 Mbs of
memory.
Is there some way to monitor the things that SQL is doing in the BACKGROUND
to these tables?
"Jeff Dillon" <jeff@.removeemergencyreporting.com> wrote in message
news:ORaVrEcvEHA.2584@.TK2MSFTNGP10.phx.gbl...
> Of course you backed up your database, prior to making major changes to
> tables, correct?
> Whew..thank goodness.
> And no, generally records are not deleted. However, behind the scenes,
it's
> probably renaming the table, creating a new structure, then inserting the
> records, then dropping and renaming the temp table.
> Did you check if the data was there immediately after changing the column
> datatype?
> Jeff
> "John Bishop" <ugradfrnd@.aol.com> wrote in message
> news:eDbrR9bvEHA.3896@.TK2MSFTNGP09.phx.gbl...
work[vbcol=seagreen]
> the
extract.[vbcol=seagreen]
> think).
> two
> Thereafter,
> datastructure
IS[vbcol=seagreen]
within[vbcol=seagreen]
> a
data[vbcol=seagreen]
>Run DBCC UPDATEUSAGE to correct the row count display in Enterprise Mangler.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"John Bishop" <ugradfrnd@.aol.com> wrote in message
news:%231Z4HYcvEHA.2016@.TK2MSFTNGP15.phx.gbl...
> Your explanation makes SENSE and yes, it appears that I was checking
> immediately after the change. (Bear in mind that I am still feeling my
way
> along.)
> The indication that the records were DELETED is that Server Enterprise
> Manager reports that the table has ZERO Rows. I had made the change in
Data
> Type in Server Enterprise Manager and then was making notes and
documenting
> what I had done. I went back to note the record count (which I had
> previously found was conveniently reported in the Table Properties in
Server
> Enterprise Manager and it gave me the sensation that ALL of the data had
> been deleted.
> Now, I am thinking that it is doing precisely as you describe. I was able
> to use the Import and Export Data tool to COPY all of the data from that
> table to another table in a different database, which reports that it has
> 387,825 records (CORRECT). The original table STILL says in the
Properties
> that it has ZERO records, but that table has several Indices that are
> probably being rebuilt.
> But, the larger database from last night STILL SAYS that it has ZERO
records
> nine hours after the records appeared to all be deleted. But it has nine
> million records and more than a few indices. And I am running this SQL
> Evaulation on an older 866 MHz single processor system with only 512 Mbs
of
> memory.
> Is there some way to monitor the things that SQL is doing in the
BACKGROUND
> to these tables?
> "Jeff Dillon" <jeff@.removeemergencyreporting.com> wrote in message
> news:ORaVrEcvEHA.2584@.TK2MSFTNGP10.phx.gbl...
> it's
the[vbcol=seagreen]
column[vbcol=seagreen]
(Friday,[vbcol=seagreen]
> work
of[vbcol=seagreen]
> extract.
of[vbcol=seagreen]
> IS
> within
> data
>
Friday, March 9, 2012
Maximum Length of Report Reached in Report Designer- Bug?
We have reached the maximum length that Report Designer allows - 180 inches.
The problem is that we need to make the report longer. Also - it appears that
the maximum size for a rectangle is 60 inches - this also is too small. Does
anyone know how to report these items to Microsoft Reporting Services
Development as an enhancement request / defect?According to the MS webinar, the page problem has been fixed. The
webinar info has been posted to the WIKI:
http://www.reportingservicesfaq.com/ow.asp?SP2ForRS%3F
jstocker101 wrote:
> We have reached the maximum length that Report Designer allows - 180 inches.
> The problem is that we need to make the report longer. Also - it appears that
> the maximum size for a rectangle is 60 inches - this also is too small. Does
> anyone know how to report these items to Microsoft Reporting Services
> Development as an enhancement request / defect?|||You might be refering to 883501 but that is a different bug. The
details of that bug are related to an error message you get when you
export to Excel. Here is that article:
http://support.microsoft.com/kb/883501
But the problem we are having would not be fixed by Reporting Services
Service Pack 2. Again, the Report Designer tool does not allow you to
create a report larger than 180 inches, and rectangles are limited to
inches. After reviewing the bugs fixed in Reporting Services SP2, none
of the fixes address this issue.
This is a major problem because you cannot create a large report in
Reporting Services!!
Jerry wrote:
> According to the MS webinar, the page problem has been fixed. The
> webinar info has been posted to the WIKI:
> http://www.reportingservicesfaq.com/ow.asp?SP2ForRS%3F
>
>
> jstocker101 wrote:
> > We have reached the maximum length that Report Designer allows -
180 inches.
> > The problem is that we need to make the report longer. Also - it
appears that
> > the maximum size for a rectangle is 60 inches - this also is too
small. Does
> > anyone know how to report these items to Microsoft Reporting
Services
> > Development as an enhancement request / defect?|||In SP2, the maximum height or width for any object is 160 inches. I'm
interested in the scenario that requires such a long report. Can you design
your report as subreports and combine the subreports together in one large
report?
--
Albert Yen
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
<jstocker@.gmail.com> wrote in message
news:1109014748.413769.319290@.f14g2000cwb.googlegroups.com...
> You might be refering to 883501 but that is a different bug. The
> details of that bug are related to an error message you get when you
> export to Excel. Here is that article:
> http://support.microsoft.com/kb/883501
> But the problem we are having would not be fixed by Reporting Services
> Service Pack 2. Again, the Report Designer tool does not allow you to
> create a report larger than 180 inches, and rectangles are limited to
> inches. After reviewing the bugs fixed in Reporting Services SP2, none
> of the fixes address this issue.
> This is a major problem because you cannot create a large report in
> Reporting Services!!
>
> Jerry wrote:
> > According to the MS webinar, the page problem has been fixed. The
> > webinar info has been posted to the WIKI:
> >
> > http://www.reportingservicesfaq.com/ow.asp?SP2ForRS%3F
> >
> >
> >
> >
> > jstocker101 wrote:
> > > We have reached the maximum length that Report Designer allows -
> 180 inches.
> > > The problem is that we need to make the report longer. Also - it
> appears that
> > > the maximum size for a rectangle is 60 inches - this also is too
> small. Does
> > > anyone know how to report these items to Microsoft Reporting
> Services
> > > Development as an enhancement request / defect?
>|||We require one long report because when we export to PDF, we need the
report to display each section as a bookmark to PDF and subreports do
not exhibit this appearance after conversion to PDF. In other words,
create a rectangle in report designer, then export to pdf and you will
notice that the rectangle will appear as a navigation tab on the left
within Acrobat reader. We have reached the limit of 160 inches and we
need to add more tabs to the report.
Regardless of whether the workaround you suggest is valid, the point is
that there should be no limit to the length of a report. That should be
up to the developer.
Albert Yen [MSFT] wrote:
> In SP2, the maximum height or width for any object is 160 inches.
I'm
> interested in the scenario that requires such a long report. Can you
design
> your report as subreports and combine the subreports together in one
large
> report?
> --
> Albert Yen
> SQL Server Reporting Services
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> <jstocker@.gmail.com> wrote in message
> news:1109014748.413769.319290@.f14g2000cwb.googlegroups.com...
> > You might be refering to 883501 but that is a different bug. The
> > details of that bug are related to an error message you get when
you
> > export to Excel. Here is that article:
> > http://support.microsoft.com/kb/883501
> >
> > But the problem we are having would not be fixed by Reporting
Services
> > Service Pack 2. Again, the Report Designer tool does not allow you
to
> > create a report larger than 180 inches, and rectangles are limited
to
> > inches. After reviewing the bugs fixed in Reporting Services SP2,
none
> > of the fixes address this issue.
> >
> > This is a major problem because you cannot create a large report in
> > Reporting Services!!
> >
> >
> >
> > Jerry wrote:
> > > According to the MS webinar, the page problem has been fixed. The
> > > webinar info has been posted to the WIKI:
> > >
> > > http://www.reportingservicesfaq.com/ow.asp?SP2ForRS%3F
> > >
> > >
> > >
> > >
> > > jstocker101 wrote:
> > > > We have reached the maximum length that Report Designer allows
-
> > 180 inches.
> > > > The problem is that we need to make the report longer. Also -
it
> > appears that
> > > > the maximum size for a rectangle is 60 inches - this also is
too
> > small. Does
> > > > anyone know how to report these items to Microsoft Reporting
> > Services
> > > > Development as an enhancement request / defect?
> >|||I have the exact same problem. Did you solve this problem - and how did you solve it
From http://66.102.9.104/search?q=cache:RcuHA1_q0zkJ:www.developmentnow.com/g/115_2005_1_0_0_455194/Maximum-Length-of-Report-Reached-in-Report-Designer-Bug.htm+"reporting+services"+"maximum+height"&hl=da&ct=clnk&cd=7&gl=d
Posted via DevelopmentNow.com Group
http://www.developmentnow.com
The problem is that we need to make the report longer. Also - it appears that
the maximum size for a rectangle is 60 inches - this also is too small. Does
anyone know how to report these items to Microsoft Reporting Services
Development as an enhancement request / defect?According to the MS webinar, the page problem has been fixed. The
webinar info has been posted to the WIKI:
http://www.reportingservicesfaq.com/ow.asp?SP2ForRS%3F
jstocker101 wrote:
> We have reached the maximum length that Report Designer allows - 180 inches.
> The problem is that we need to make the report longer. Also - it appears that
> the maximum size for a rectangle is 60 inches - this also is too small. Does
> anyone know how to report these items to Microsoft Reporting Services
> Development as an enhancement request / defect?|||You might be refering to 883501 but that is a different bug. The
details of that bug are related to an error message you get when you
export to Excel. Here is that article:
http://support.microsoft.com/kb/883501
But the problem we are having would not be fixed by Reporting Services
Service Pack 2. Again, the Report Designer tool does not allow you to
create a report larger than 180 inches, and rectangles are limited to
inches. After reviewing the bugs fixed in Reporting Services SP2, none
of the fixes address this issue.
This is a major problem because you cannot create a large report in
Reporting Services!!
Jerry wrote:
> According to the MS webinar, the page problem has been fixed. The
> webinar info has been posted to the WIKI:
> http://www.reportingservicesfaq.com/ow.asp?SP2ForRS%3F
>
>
> jstocker101 wrote:
> > We have reached the maximum length that Report Designer allows -
180 inches.
> > The problem is that we need to make the report longer. Also - it
appears that
> > the maximum size for a rectangle is 60 inches - this also is too
small. Does
> > anyone know how to report these items to Microsoft Reporting
Services
> > Development as an enhancement request / defect?|||In SP2, the maximum height or width for any object is 160 inches. I'm
interested in the scenario that requires such a long report. Can you design
your report as subreports and combine the subreports together in one large
report?
--
Albert Yen
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
<jstocker@.gmail.com> wrote in message
news:1109014748.413769.319290@.f14g2000cwb.googlegroups.com...
> You might be refering to 883501 but that is a different bug. The
> details of that bug are related to an error message you get when you
> export to Excel. Here is that article:
> http://support.microsoft.com/kb/883501
> But the problem we are having would not be fixed by Reporting Services
> Service Pack 2. Again, the Report Designer tool does not allow you to
> create a report larger than 180 inches, and rectangles are limited to
> inches. After reviewing the bugs fixed in Reporting Services SP2, none
> of the fixes address this issue.
> This is a major problem because you cannot create a large report in
> Reporting Services!!
>
> Jerry wrote:
> > According to the MS webinar, the page problem has been fixed. The
> > webinar info has been posted to the WIKI:
> >
> > http://www.reportingservicesfaq.com/ow.asp?SP2ForRS%3F
> >
> >
> >
> >
> > jstocker101 wrote:
> > > We have reached the maximum length that Report Designer allows -
> 180 inches.
> > > The problem is that we need to make the report longer. Also - it
> appears that
> > > the maximum size for a rectangle is 60 inches - this also is too
> small. Does
> > > anyone know how to report these items to Microsoft Reporting
> Services
> > > Development as an enhancement request / defect?
>|||We require one long report because when we export to PDF, we need the
report to display each section as a bookmark to PDF and subreports do
not exhibit this appearance after conversion to PDF. In other words,
create a rectangle in report designer, then export to pdf and you will
notice that the rectangle will appear as a navigation tab on the left
within Acrobat reader. We have reached the limit of 160 inches and we
need to add more tabs to the report.
Regardless of whether the workaround you suggest is valid, the point is
that there should be no limit to the length of a report. That should be
up to the developer.
Albert Yen [MSFT] wrote:
> In SP2, the maximum height or width for any object is 160 inches.
I'm
> interested in the scenario that requires such a long report. Can you
design
> your report as subreports and combine the subreports together in one
large
> report?
> --
> Albert Yen
> SQL Server Reporting Services
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> <jstocker@.gmail.com> wrote in message
> news:1109014748.413769.319290@.f14g2000cwb.googlegroups.com...
> > You might be refering to 883501 but that is a different bug. The
> > details of that bug are related to an error message you get when
you
> > export to Excel. Here is that article:
> > http://support.microsoft.com/kb/883501
> >
> > But the problem we are having would not be fixed by Reporting
Services
> > Service Pack 2. Again, the Report Designer tool does not allow you
to
> > create a report larger than 180 inches, and rectangles are limited
to
> > inches. After reviewing the bugs fixed in Reporting Services SP2,
none
> > of the fixes address this issue.
> >
> > This is a major problem because you cannot create a large report in
> > Reporting Services!!
> >
> >
> >
> > Jerry wrote:
> > > According to the MS webinar, the page problem has been fixed. The
> > > webinar info has been posted to the WIKI:
> > >
> > > http://www.reportingservicesfaq.com/ow.asp?SP2ForRS%3F
> > >
> > >
> > >
> > >
> > > jstocker101 wrote:
> > > > We have reached the maximum length that Report Designer allows
-
> > 180 inches.
> > > > The problem is that we need to make the report longer. Also -
it
> > appears that
> > > > the maximum size for a rectangle is 60 inches - this also is
too
> > small. Does
> > > > anyone know how to report these items to Microsoft Reporting
> > Services
> > > > Development as an enhancement request / defect?
> >|||I have the exact same problem. Did you solve this problem - and how did you solve it
From http://66.102.9.104/search?q=cache:RcuHA1_q0zkJ:www.developmentnow.com/g/115_2005_1_0_0_455194/Maximum-Length-of-Report-Reached-in-Report-Designer-Bug.htm+"reporting+services"+"maximum+height"&hl=da&ct=clnk&cd=7&gl=d
Posted via DevelopmentNow.com Group
http://www.developmentnow.com
Subscribe to:
Posts (Atom)