Hello all,
I am migrating a Paradox application to SQL Server. My problem is that the
existing Paradox table structure is limited. Correcting it will mean a
re-write of the application (Delphi app). Although the record and column
limits are higher in SQL Server, it will eventually hit the wall. So I was
wondering if anyone could offer advise on how we might do this best...
The application is essentially an evaluation tool. It is very generic and
can evaluate anything from buying a digital camera or laptop, to purchasing
a house. All the attributes of whatever it is being measure (the
attributes) are defined as a new column.
Example: let's say you are evaluating laptops. The core table may look like
this:
Fields:
1) Identifier
2) Processor Speed
3) Processor Cache
4) Hard Disk Size
5) LAN connection
6) Cost
So in this table, there are 5 things being measure, 6 columns in total. A
record might look like this:
Field Data:
Identifier | Speed | Cache | HD Size | LAN | Cost ...
HP | 3ghz | 2mb | 60G | Wireless | $2000
So you can see that this structure will hit the wall eventually as more and
more criteria are added. With Paradox, the max number of columns is 255. In
SQL Server this is 1024. Of course there is also a maximum record size. For
SQL Server this is 8060 bytes.
What I'd prefer is a structure that has no limits on how big it can be. In
short, I need a new table structure that is long and skinny, vs very wide
(or fat):
Fields:
Identifier
Attribute
Value
So using the above example, the data might look like:
Field Data
Identifier | Attribute | Value
HP | Speed | 3ghz
HP | Cache | 2mb
HP | HD Size | 60G
HP | LAN | Wireless
HP | Cost | $2000
Obviously this structure is preferred because now I won't hit any column or
record limits, but it makes just about everything else in the application
more difficult. Fundamentally data validation becomes difficult
In the above example, how would one define this structure?
Identifier varchar(50)
Attribute varchar(50)
Value ' <-- here lies my problem!!!
In some cases "value" would be an integer, sometimes numeric, sometimes
text. So then I figured, well I could have a number of tables as above,
each for the various data types, integers, numbers, free form text, etc.
Example:
For Integer data
Identifier varchar(50)
Attribute varchar(50)
Value integer
For floating point data
Identifier varchar(50)
Attribute varchar(50)
Value numeric
For free-form data
Identifier varchar(50)
Attribute varchar(50)
Value varchar or ntext
So now I have taken what was in one table, and split it across 3 or more
tables. Of course, all this data would need to be "re-connected" in a grid
like fashion so it looks like just one row of data to the client again.
It all seems to be getting very messy - to simply overcome a column/row
size limitation. Surely there must be an eloquent way to do something like
this?
thanx very much for any input.
regards,
-randall sell"Randall Sell" <randall@.bytewise.nospam.com.au> wrote in message
news:lsjYc.12329$D7.11613@.news-server.bigpond.net.au...
> Hello all,
> I am migrating a Paradox application to SQL Server. My problem is that the
> existing Paradox table structure is limited. Correcting it will mean a
> re-write of the application (Delphi app). Although the record and column
> limits are higher in SQL Server, it will eventually hit the wall. So I was
> wondering if anyone could offer advise on how we might do this best...
>
. . .
> So now I have taken what was in one table, and split it across 3 or more
> tables. Of course, all this data would need to be "re-connected" in a grid
> like fashion so it looks like just one row of data to the client again.
> It all seems to be getting very messy - to simply overcome a column/row
> size limitation. Surely there must be an eloquent way to do something like
> this?
>
You have pretty much worked through he issues here. And you're right: the
free-form attribute storage is a pain to manage, has no data integrity and
performs terribly. I'll just add that it's also not what relational
databases are _for_. An RDBMS is designed to model data using relations. A
relation is a tuple of related values, like
( HP, 3ghz, 2mb, 60G, Wireless, $2000 )
So the original design is the correct one. Mainly for performance reasons,
SqlServer puts a limit on the size of rows (in bytes and in number of
columns). If you really run out of room, you can always just create a
second table, and a third, etc which have a one-to-one relationship with
your original table.
David|||Now why didn't I think of that? That is the sort of input I was looking
for. It would also have some problems, such as creating dynamic queries and
not knowing which table contains a field, but the meta data should sort
that out, so it should be manageable.
thanx
-randall
David Browne wrote:
> So the original design is the correct one. Mainly for performance reasons
,
> SqlServer puts a limit on the size of rows (in bytes and in number of
> columns). If you really run out of room, you can always just create a
> second table, and a third, etc which have a one-to-one relationship with
> your original table.
> David
>
Showing posts with label structure. Show all posts
Showing posts with label structure. Show all posts
Monday, March 26, 2012
Proper table structure and SQL Server limits
Hello all,
I am migrating a Paradox application to SQL Server. My problem is that the
existing Paradox table structure is limited. Correcting it will mean a
re-write of the application (Delphi app). Although the record and column
limits are higher in SQL Server, it will eventually hit the wall. So I was
wondering if anyone could offer advise on how we might do this best...
The application is essentially an evaluation tool. It is very generic and
can evaluate anything from buying a digital camera or laptop, to purchasing
a house. All the attributes of whatever it is being measure (the
attributes) are defined as a new column.
Example: let's say you are evaluating laptops. The core table may look like
this:
Fields:
1) Identifier
2) Processor Speed
3) Processor Cache
4) Hard Disk Size
5) LAN connection
6) Cost
So in this table, there are 5 things being measure, 6 columns in total. A
record might look like this:
Field Data:
Identifier | Speed | Cache | HD Size | LAN | Cost ...
HP | 3ghz | 2mb | 60G | Wireless | $2000
So you can see that this structure will hit the wall eventually as more and
more criteria are added. With Paradox, the max number of columns is 255. In
SQL Server this is 1024. Of course there is also a maximum record size. For
SQL Server this is 8060 bytes.
What I'd prefer is a structure that has no limits on how big it can be. In
short, I need a new table structure that is long and skinny, vs very wide
(or fat):
Fields:
Identifier
Attribute
Value
So using the above example, the data might look like:
Field Data
Identifier | Attribute | Value
HP | Speed | 3ghz
HP | Cache | 2mb
HP | HD Size | 60G
HP | LAN | Wireless
HP | Cost | $2000
Obviously this structure is preferred because now I won't hit any column or
record limits, but it makes just about everything else in the application
more difficult. Fundamentally data validation becomes difficult
In the above example, how would one define this structure?
Identifier varchar(50)
Attribute varchar(50)
Value ' <-- here lies my problem!!!
In some cases "value" would be an integer, sometimes numeric, sometimes
text. So then I figured, well I could have a number of tables as above,
each for the various data types, integers, numbers, free form text, etc.
Example:
For Integer data
Identifier varchar(50)
Attribute varchar(50)
Value integer
For floating point data
Identifier varchar(50)
Attribute varchar(50)
Value numeric
For free-form data
Identifier varchar(50)
Attribute varchar(50)
Value varchar or ntext
So now I have taken what was in one table, and split it across 3 or more
tables. Of course, all this data would need to be "re-connected" in a grid
like fashion so it looks like just one row of data to the client again.
It all seems to be getting very messy - to simply overcome a column/row
size limitation. Surely there must be an eloquent way to do something like
this?
thanx very much for any input.
regards,
-randall sell"Randall Sell" <randall@.bytewise.nospam.com.au> wrote in message
news:lsjYc.12329$D7.11613@.news-server.bigpond.net.au...
> Hello all,
> I am migrating a Paradox application to SQL Server. My problem is that the
> existing Paradox table structure is limited. Correcting it will mean a
> re-write of the application (Delphi app). Although the record and column
> limits are higher in SQL Server, it will eventually hit the wall. So I was
> wondering if anyone could offer advise on how we might do this best...
>
. . .
> So now I have taken what was in one table, and split it across 3 or more
> tables. Of course, all this data would need to be "re-connected" in a grid
> like fashion so it looks like just one row of data to the client again.
> It all seems to be getting very messy - to simply overcome a column/row
> size limitation. Surely there must be an eloquent way to do something like
> this?
>
You have pretty much worked through he issues here. And you're right: the
free-form attribute storage is a pain to manage, has no data integrity and
performs terribly. I'll just add that it's also not what relational
databases are _for_. An RDBMS is designed to model data using relations. A
relation is a tuple of related values, like
( HP, 3ghz, 2mb, 60G, Wireless, $2000 )
So the original design is the correct one. Mainly for performance reasons,
SqlServer puts a limit on the size of rows (in bytes and in number of
columns). If you really run out of room, you can always just create a
second table, and a third, etc which have a one-to-one relationship with
your original table.
David|||Now why didn't I think of that? That is the sort of input I was looking
for. It would also have some problems, such as creating dynamic queries and
not knowing which table contains a field, but the meta data should sort
that out, so it should be manageable.
thanx
-randall
David Browne wrote:
> So the original design is the correct one. Mainly for performance reasons,
> SqlServer puts a limit on the size of rows (in bytes and in number of
> columns). If you really run out of room, you can always just create a
> second table, and a third, etc which have a one-to-one relationship with
> your original table.
> David
>sql
I am migrating a Paradox application to SQL Server. My problem is that the
existing Paradox table structure is limited. Correcting it will mean a
re-write of the application (Delphi app). Although the record and column
limits are higher in SQL Server, it will eventually hit the wall. So I was
wondering if anyone could offer advise on how we might do this best...
The application is essentially an evaluation tool. It is very generic and
can evaluate anything from buying a digital camera or laptop, to purchasing
a house. All the attributes of whatever it is being measure (the
attributes) are defined as a new column.
Example: let's say you are evaluating laptops. The core table may look like
this:
Fields:
1) Identifier
2) Processor Speed
3) Processor Cache
4) Hard Disk Size
5) LAN connection
6) Cost
So in this table, there are 5 things being measure, 6 columns in total. A
record might look like this:
Field Data:
Identifier | Speed | Cache | HD Size | LAN | Cost ...
HP | 3ghz | 2mb | 60G | Wireless | $2000
So you can see that this structure will hit the wall eventually as more and
more criteria are added. With Paradox, the max number of columns is 255. In
SQL Server this is 1024. Of course there is also a maximum record size. For
SQL Server this is 8060 bytes.
What I'd prefer is a structure that has no limits on how big it can be. In
short, I need a new table structure that is long and skinny, vs very wide
(or fat):
Fields:
Identifier
Attribute
Value
So using the above example, the data might look like:
Field Data
Identifier | Attribute | Value
HP | Speed | 3ghz
HP | Cache | 2mb
HP | HD Size | 60G
HP | LAN | Wireless
HP | Cost | $2000
Obviously this structure is preferred because now I won't hit any column or
record limits, but it makes just about everything else in the application
more difficult. Fundamentally data validation becomes difficult
In the above example, how would one define this structure?
Identifier varchar(50)
Attribute varchar(50)
Value ' <-- here lies my problem!!!
In some cases "value" would be an integer, sometimes numeric, sometimes
text. So then I figured, well I could have a number of tables as above,
each for the various data types, integers, numbers, free form text, etc.
Example:
For Integer data
Identifier varchar(50)
Attribute varchar(50)
Value integer
For floating point data
Identifier varchar(50)
Attribute varchar(50)
Value numeric
For free-form data
Identifier varchar(50)
Attribute varchar(50)
Value varchar or ntext
So now I have taken what was in one table, and split it across 3 or more
tables. Of course, all this data would need to be "re-connected" in a grid
like fashion so it looks like just one row of data to the client again.
It all seems to be getting very messy - to simply overcome a column/row
size limitation. Surely there must be an eloquent way to do something like
this?
thanx very much for any input.
regards,
-randall sell"Randall Sell" <randall@.bytewise.nospam.com.au> wrote in message
news:lsjYc.12329$D7.11613@.news-server.bigpond.net.au...
> Hello all,
> I am migrating a Paradox application to SQL Server. My problem is that the
> existing Paradox table structure is limited. Correcting it will mean a
> re-write of the application (Delphi app). Although the record and column
> limits are higher in SQL Server, it will eventually hit the wall. So I was
> wondering if anyone could offer advise on how we might do this best...
>
. . .
> So now I have taken what was in one table, and split it across 3 or more
> tables. Of course, all this data would need to be "re-connected" in a grid
> like fashion so it looks like just one row of data to the client again.
> It all seems to be getting very messy - to simply overcome a column/row
> size limitation. Surely there must be an eloquent way to do something like
> this?
>
You have pretty much worked through he issues here. And you're right: the
free-form attribute storage is a pain to manage, has no data integrity and
performs terribly. I'll just add that it's also not what relational
databases are _for_. An RDBMS is designed to model data using relations. A
relation is a tuple of related values, like
( HP, 3ghz, 2mb, 60G, Wireless, $2000 )
So the original design is the correct one. Mainly for performance reasons,
SqlServer puts a limit on the size of rows (in bytes and in number of
columns). If you really run out of room, you can always just create a
second table, and a third, etc which have a one-to-one relationship with
your original table.
David|||Now why didn't I think of that? That is the sort of input I was looking
for. It would also have some problems, such as creating dynamic queries and
not knowing which table contains a field, but the meta data should sort
that out, so it should be manageable.
thanx
-randall
David Browne wrote:
> So the original design is the correct one. Mainly for performance reasons,
> SqlServer puts a limit on the size of rows (in bytes and in number of
> columns). If you really run out of room, you can always just create a
> second table, and a third, etc which have a one-to-one relationship with
> your original table.
> David
>sql
Proper table structure and SQL Server limits
Hello all,
I am migrating a Paradox application to SQL Server. My problem is that the
existing Paradox table structure is limited. Correcting it will mean a
re-write of the application (Delphi app). Although the record and column
limits are higher in SQL Server, it will eventually hit the wall. So I was
wondering if anyone could offer advise on how we might do this best...
The application is essentially an evaluation tool. It is very generic and
can evaluate anything from buying a digital camera or laptop, to purchasing
a house. All the attributes of whatever it is being measure (the
attributes) are defined as a new column.
Example: let's say you are evaluating laptops. The core table may look like
this:
Fields:
1) Identifier
2) Processor Speed
3) Processor Cache
4) Hard Disk Size
5) LAN connection
6) Cost
So in this table, there are 5 things being measure, 6 columns in total. A
record might look like this:
Field Data:
Identifier | Speed | Cache | HD Size | LAN | Cost ...
HP | 3ghz | 2mb | 60G | Wireless | $2000
So you can see that this structure will hit the wall eventually as more and
more criteria are added. With Paradox, the max number of columns is 255. In
SQL Server this is 1024. Of course there is also a maximum record size. For
SQL Server this is 8060 bytes.
What I'd prefer is a structure that has no limits on how big it can be. In
short, I need a new table structure that is long and skinny, vs very wide
(or fat):
Fields:
Identifier
Attribute
Value
So using the above example, the data might look like:
Field Data
Identifier | Attribute | Value
HP | Speed | 3ghz
HP | Cache | 2mb
HP | HD Size | 60G
HP | LAN | Wireless
HP | Cost | $2000
Obviously this structure is preferred because now I won't hit any column or
record limits, but it makes just about everything else in the application
more difficult. Fundamentally data validation becomes difficult
In the above example, how would one define this structure?
Identifier varchar(50)
Attribute varchar(50)
Value ? <-- here lies my problem!!!
In some cases "value" would be an integer, sometimes numeric, sometimes
text. So then I figured, well I could have a number of tables as above,
each for the various data types, integers, numbers, free form text, etc.
Example:
For Integer data
Identifier varchar(50)
Attribute varchar(50)
Value integer
For floating point data
Identifier varchar(50)
Attribute varchar(50)
Value numeric
For free-form data
Identifier varchar(50)
Attribute varchar(50)
Value varchar or ntext
So now I have taken what was in one table, and split it across 3 or more
tables. Of course, all this data would need to be "re-connected" in a grid
like fashion so it looks like just one row of data to the client again.
It all seems to be getting very messy - to simply overcome a column/row
size limitation. Surely there must be an eloquent way to do something like
this?
thanx very much for any input.
regards,
-randall sell
"Randall Sell" <randall@.bytewise.nospam.com.au> wrote in message
news:lsjYc.12329$D7.11613@.news-server.bigpond.net.au...
> Hello all,
> I am migrating a Paradox application to SQL Server. My problem is that the
> existing Paradox table structure is limited. Correcting it will mean a
> re-write of the application (Delphi app). Although the record and column
> limits are higher in SQL Server, it will eventually hit the wall. So I was
> wondering if anyone could offer advise on how we might do this best...
>
.. . .
> So now I have taken what was in one table, and split it across 3 or more
> tables. Of course, all this data would need to be "re-connected" in a grid
> like fashion so it looks like just one row of data to the client again.
> It all seems to be getting very messy - to simply overcome a column/row
> size limitation. Surely there must be an eloquent way to do something like
> this?
>
You have pretty much worked through he issues here. And you're right: the
free-form attribute storage is a pain to manage, has no data integrity and
performs terribly. I'll just add that it's also not what relational
databases are _for_. An RDBMS is designed to model data using relations. A
relation is a tuple of related values, like
( HP, 3ghz, 2mb, 60G, Wireless, $2000 )
So the original design is the correct one. Mainly for performance reasons,
SqlServer puts a limit on the size of rows (in bytes and in number of
columns). If you really run out of room, you can always just create a
second table, and a third, etc which have a one-to-one relationship with
your original table.
David
|||Now why didn't I think of that? That is the sort of input I was looking
for. It would also have some problems, such as creating dynamic queries and
not knowing which table contains a field, but the meta data should sort
that out, so it should be manageable.
thanx
-randall
David Browne wrote:
> So the original design is the correct one. Mainly for performance reasons,
> SqlServer puts a limit on the size of rows (in bytes and in number of
> columns). If you really run out of room, you can always just create a
> second table, and a third, etc which have a one-to-one relationship with
> your original table.
> David
>
I am migrating a Paradox application to SQL Server. My problem is that the
existing Paradox table structure is limited. Correcting it will mean a
re-write of the application (Delphi app). Although the record and column
limits are higher in SQL Server, it will eventually hit the wall. So I was
wondering if anyone could offer advise on how we might do this best...
The application is essentially an evaluation tool. It is very generic and
can evaluate anything from buying a digital camera or laptop, to purchasing
a house. All the attributes of whatever it is being measure (the
attributes) are defined as a new column.
Example: let's say you are evaluating laptops. The core table may look like
this:
Fields:
1) Identifier
2) Processor Speed
3) Processor Cache
4) Hard Disk Size
5) LAN connection
6) Cost
So in this table, there are 5 things being measure, 6 columns in total. A
record might look like this:
Field Data:
Identifier | Speed | Cache | HD Size | LAN | Cost ...
HP | 3ghz | 2mb | 60G | Wireless | $2000
So you can see that this structure will hit the wall eventually as more and
more criteria are added. With Paradox, the max number of columns is 255. In
SQL Server this is 1024. Of course there is also a maximum record size. For
SQL Server this is 8060 bytes.
What I'd prefer is a structure that has no limits on how big it can be. In
short, I need a new table structure that is long and skinny, vs very wide
(or fat):
Fields:
Identifier
Attribute
Value
So using the above example, the data might look like:
Field Data
Identifier | Attribute | Value
HP | Speed | 3ghz
HP | Cache | 2mb
HP | HD Size | 60G
HP | LAN | Wireless
HP | Cost | $2000
Obviously this structure is preferred because now I won't hit any column or
record limits, but it makes just about everything else in the application
more difficult. Fundamentally data validation becomes difficult
In the above example, how would one define this structure?
Identifier varchar(50)
Attribute varchar(50)
Value ? <-- here lies my problem!!!
In some cases "value" would be an integer, sometimes numeric, sometimes
text. So then I figured, well I could have a number of tables as above,
each for the various data types, integers, numbers, free form text, etc.
Example:
For Integer data
Identifier varchar(50)
Attribute varchar(50)
Value integer
For floating point data
Identifier varchar(50)
Attribute varchar(50)
Value numeric
For free-form data
Identifier varchar(50)
Attribute varchar(50)
Value varchar or ntext
So now I have taken what was in one table, and split it across 3 or more
tables. Of course, all this data would need to be "re-connected" in a grid
like fashion so it looks like just one row of data to the client again.
It all seems to be getting very messy - to simply overcome a column/row
size limitation. Surely there must be an eloquent way to do something like
this?
thanx very much for any input.
regards,
-randall sell
"Randall Sell" <randall@.bytewise.nospam.com.au> wrote in message
news:lsjYc.12329$D7.11613@.news-server.bigpond.net.au...
> Hello all,
> I am migrating a Paradox application to SQL Server. My problem is that the
> existing Paradox table structure is limited. Correcting it will mean a
> re-write of the application (Delphi app). Although the record and column
> limits are higher in SQL Server, it will eventually hit the wall. So I was
> wondering if anyone could offer advise on how we might do this best...
>
.. . .
> So now I have taken what was in one table, and split it across 3 or more
> tables. Of course, all this data would need to be "re-connected" in a grid
> like fashion so it looks like just one row of data to the client again.
> It all seems to be getting very messy - to simply overcome a column/row
> size limitation. Surely there must be an eloquent way to do something like
> this?
>
You have pretty much worked through he issues here. And you're right: the
free-form attribute storage is a pain to manage, has no data integrity and
performs terribly. I'll just add that it's also not what relational
databases are _for_. An RDBMS is designed to model data using relations. A
relation is a tuple of related values, like
( HP, 3ghz, 2mb, 60G, Wireless, $2000 )
So the original design is the correct one. Mainly for performance reasons,
SqlServer puts a limit on the size of rows (in bytes and in number of
columns). If you really run out of room, you can always just create a
second table, and a third, etc which have a one-to-one relationship with
your original table.
David
|||Now why didn't I think of that? That is the sort of input I was looking
for. It would also have some problems, such as creating dynamic queries and
not knowing which table contains a field, but the meta data should sort
that out, so it should be manageable.
thanx
-randall
David Browne wrote:
> So the original design is the correct one. Mainly for performance reasons,
> SqlServer puts a limit on the size of rows (in bytes and in number of
> columns). If you really run out of room, you can always just create a
> second table, and a third, etc which have a one-to-one relationship with
> your original table.
> David
>
Wednesday, March 21, 2012
Project structure when using RepSvcs
Hi,
I have a WinForm project in VS .NET and need to incorporate Reporting
Services.
The application will display the reports to the users on a form with an IE
control.
Is it possible to add the report items to the application project? or
Must I create a separate project of type report and have the reports there?
How could the reports be invoked by the application?
Thanks in advance,
RichardIf you are using IE control you have only one choice. One, the reports need
to be in their own project. Two, they have to be deployed to a server in
order to test your links.
As far as invoking the reports, it confuses me. You stated that you are
using the IE control. The only way to use this control is doing URL
integration. All you are doing is assembling a string and setting the URL
property for the control.
I guess in a convoluted way you could use web services, stream the html to a
file and give the IE control a
If you are using VS.Net 2005 then look at the new controls. There is a
winform and webform controls. The new winform control is a much better way
of integrating reports (I am using it in a Winform application. I use IE
control in a In-Touch application... real time control user interface).
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Richard" <Richard@.discussions.microsoft.com> wrote in message
news:F4FA857A-45A2-4158-A1ED-C238D66D6CD2@.microsoft.com...
> Hi,
> I have a WinForm project in VS .NET and need to incorporate Reporting
> Services.
> The application will display the reports to the users on a form with an IE
> control.
> Is it possible to add the report items to the application project? or
> Must I create a separate project of type report and have the reports
> there?
> How could the reports be invoked by the application?
> Thanks in advance,
> Richard|||Sorry Bruce, I meant a ReportViewer control on a WinForm.
"Bruce L-C [MVP]" wrote:
> If you are using IE control you have only one choice. One, the reports need
> to be in their own project. Two, they have to be deployed to a server in
> order to test your links.
> As far as invoking the reports, it confuses me. You stated that you are
> using the IE control. The only way to use this control is doing URL
> integration. All you are doing is assembling a string and setting the URL
> property for the control.
> I guess in a convoluted way you could use web services, stream the html to a
> file and give the IE control a
> If you are using VS.Net 2005 then look at the new controls. There is a
> winform and webform controls. The new winform control is a much better way
> of integrating reports (I am using it in a Winform application. I use IE
> control in a In-Touch application... real time control user interface).
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Richard" <Richard@.discussions.microsoft.com> wrote in message
> news:F4FA857A-45A2-4158-A1ED-C238D66D6CD2@.microsoft.com...
> > Hi,
> >
> > I have a WinForm project in VS .NET and need to incorporate Reporting
> > Services.
> > The application will display the reports to the users on a form with an IE
> > control.
> > Is it possible to add the report items to the application project? or
> > Must I create a separate project of type report and have the reports
> > there?
> > How could the reports be invoked by the application?
> >
> > Thanks in advance,
> >
> > Richard
>
>|||Ahhh, HUGE difference. There are two ways to use the Winform control: server
and local mode.
Server mode, develop your reports in a reports project, separately. Test out
your report there, deploy and then integrate with Winform control (which is
what I do).
Local mode. Develop report initially in a reports project. Test out report.
Copy rdl file, renaming it to rdlc. Bring the rdlc into your winform
project. Note that you do have much more to do to get full functionality of
a report in local mode. It is nowhere near as simple as integrating in a
report which is deployed to a server.
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Richard" <Richard@.discussions.microsoft.com> wrote in message
news:5820FB57-5FC6-4742-A571-1531CC73E4E0@.microsoft.com...
> Sorry Bruce, I meant a ReportViewer control on a WinForm.
> "Bruce L-C [MVP]" wrote:
>> If you are using IE control you have only one choice. One, the reports
>> need
>> to be in their own project. Two, they have to be deployed to a server in
>> order to test your links.
>> As far as invoking the reports, it confuses me. You stated that you are
>> using the IE control. The only way to use this control is doing URL
>> integration. All you are doing is assembling a string and setting the URL
>> property for the control.
>> I guess in a convoluted way you could use web services, stream the html
>> to a
>> file and give the IE control a
>> If you are using VS.Net 2005 then look at the new controls. There is a
>> winform and webform controls. The new winform control is a much better
>> way
>> of integrating reports (I am using it in a Winform application. I use IE
>> control in a In-Touch application... real time control user interface).
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Richard" <Richard@.discussions.microsoft.com> wrote in message
>> news:F4FA857A-45A2-4158-A1ED-C238D66D6CD2@.microsoft.com...
>> > Hi,
>> >
>> > I have a WinForm project in VS .NET and need to incorporate Reporting
>> > Services.
>> > The application will display the reports to the users on a form with an
>> > IE
>> > control.
>> > Is it possible to add the report items to the application project? or
>> > Must I create a separate project of type report and have the reports
>> > there?
>> > How could the reports be invoked by the application?
>> >
>> > Thanks in advance,
>> >
>> > Richard
>>
I have a WinForm project in VS .NET and need to incorporate Reporting
Services.
The application will display the reports to the users on a form with an IE
control.
Is it possible to add the report items to the application project? or
Must I create a separate project of type report and have the reports there?
How could the reports be invoked by the application?
Thanks in advance,
RichardIf you are using IE control you have only one choice. One, the reports need
to be in their own project. Two, they have to be deployed to a server in
order to test your links.
As far as invoking the reports, it confuses me. You stated that you are
using the IE control. The only way to use this control is doing URL
integration. All you are doing is assembling a string and setting the URL
property for the control.
I guess in a convoluted way you could use web services, stream the html to a
file and give the IE control a
If you are using VS.Net 2005 then look at the new controls. There is a
winform and webform controls. The new winform control is a much better way
of integrating reports (I am using it in a Winform application. I use IE
control in a In-Touch application... real time control user interface).
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Richard" <Richard@.discussions.microsoft.com> wrote in message
news:F4FA857A-45A2-4158-A1ED-C238D66D6CD2@.microsoft.com...
> Hi,
> I have a WinForm project in VS .NET and need to incorporate Reporting
> Services.
> The application will display the reports to the users on a form with an IE
> control.
> Is it possible to add the report items to the application project? or
> Must I create a separate project of type report and have the reports
> there?
> How could the reports be invoked by the application?
> Thanks in advance,
> Richard|||Sorry Bruce, I meant a ReportViewer control on a WinForm.
"Bruce L-C [MVP]" wrote:
> If you are using IE control you have only one choice. One, the reports need
> to be in their own project. Two, they have to be deployed to a server in
> order to test your links.
> As far as invoking the reports, it confuses me. You stated that you are
> using the IE control. The only way to use this control is doing URL
> integration. All you are doing is assembling a string and setting the URL
> property for the control.
> I guess in a convoluted way you could use web services, stream the html to a
> file and give the IE control a
> If you are using VS.Net 2005 then look at the new controls. There is a
> winform and webform controls. The new winform control is a much better way
> of integrating reports (I am using it in a Winform application. I use IE
> control in a In-Touch application... real time control user interface).
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Richard" <Richard@.discussions.microsoft.com> wrote in message
> news:F4FA857A-45A2-4158-A1ED-C238D66D6CD2@.microsoft.com...
> > Hi,
> >
> > I have a WinForm project in VS .NET and need to incorporate Reporting
> > Services.
> > The application will display the reports to the users on a form with an IE
> > control.
> > Is it possible to add the report items to the application project? or
> > Must I create a separate project of type report and have the reports
> > there?
> > How could the reports be invoked by the application?
> >
> > Thanks in advance,
> >
> > Richard
>
>|||Ahhh, HUGE difference. There are two ways to use the Winform control: server
and local mode.
Server mode, develop your reports in a reports project, separately. Test out
your report there, deploy and then integrate with Winform control (which is
what I do).
Local mode. Develop report initially in a reports project. Test out report.
Copy rdl file, renaming it to rdlc. Bring the rdlc into your winform
project. Note that you do have much more to do to get full functionality of
a report in local mode. It is nowhere near as simple as integrating in a
report which is deployed to a server.
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Richard" <Richard@.discussions.microsoft.com> wrote in message
news:5820FB57-5FC6-4742-A571-1531CC73E4E0@.microsoft.com...
> Sorry Bruce, I meant a ReportViewer control on a WinForm.
> "Bruce L-C [MVP]" wrote:
>> If you are using IE control you have only one choice. One, the reports
>> need
>> to be in their own project. Two, they have to be deployed to a server in
>> order to test your links.
>> As far as invoking the reports, it confuses me. You stated that you are
>> using the IE control. The only way to use this control is doing URL
>> integration. All you are doing is assembling a string and setting the URL
>> property for the control.
>> I guess in a convoluted way you could use web services, stream the html
>> to a
>> file and give the IE control a
>> If you are using VS.Net 2005 then look at the new controls. There is a
>> winform and webform controls. The new winform control is a much better
>> way
>> of integrating reports (I am using it in a Winform application. I use IE
>> control in a In-Touch application... real time control user interface).
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Richard" <Richard@.discussions.microsoft.com> wrote in message
>> news:F4FA857A-45A2-4158-A1ED-C238D66D6CD2@.microsoft.com...
>> > Hi,
>> >
>> > I have a WinForm project in VS .NET and need to incorporate Reporting
>> > Services.
>> > The application will display the reports to the users on a form with an
>> > IE
>> > control.
>> > Is it possible to add the report items to the application project? or
>> > Must I create a separate project of type report and have the reports
>> > there?
>> > How could the reports be invoked by the application?
>> >
>> > Thanks in advance,
>> >
>> > Richard
>>
Wednesday, March 7, 2012
Programmatically copy table structure?
I have been looking for a way to copy the table definition (column, identities, default constraints, etc) programmatically between databases.
I have tried 'select * into...' but that only copies column names, data types and nullibility.
sp_helptext does not have any data on table objects.
I have tried 'select * into...' but that only copies column names, data types and nullibility.
sp_helptext does not have any data on table objects.
So, the only thing I can think of is to use DDL triggers to keep the tables in sync. But I would prefer a method where I could run a stored procedure with a table name and have it return the DDL to create that table.
Any help would be welcome.
-Preston M. Price
You should use a management API like SQL DMO/SMO instead of writing server side code. There is no built-in mechanism on the server-side to do scripting - you have to write your own code. DMO/SMO have objects to script schema easily but not changes comparing two tables for example. It is not clear if you require that functionality. For comparing objects and generating schema change scripts, you need to use 3rd party tools.|||I was working with SMO and DMO and they do what I want, but there is no way to include their functionality inside a CLR stored procedure.
So as far as I can tell there is no way to programmatically (T-SQL or CLR supported procedures) copy the complete structure of a table (with or without data) from inside SQL Server, this seems like a weakness to me.
-Preston M. Price
Subscribe to:
Posts (Atom)