We are migrating a browser based application developed
with the Enterprise version to a server running the
standard edition. There will be some development on the
standard version before a new vresion of the application
is deployed. Can anyone help me to understand what
issues/problems we should look out for?Since most of the difference between Standard Edition and Enterprise Edition
involves scalability and availability features (>4 processors, large memory
support, clusters) there generally will be no problems migrating
applications from Enterprise to Standard. The few small gotchas include
Transparent Materialized Views and Distributed Partitioned Views, both of
which are only included in Enterprise Edition. (For completeness, Analysis
Services has some similar differences between Standard and Enterprise). If
you have not used these few scalability-related features then you will not
notice application level differences between these editions.
See "Features Supported by the Editions of SQL Server 2000" in Books Online.
--
Hal Berenson, SQL Server MVP
True Mountain Group LLC
"rez" <rezam@.go.com> wrote in message
news:039601c37bc5$bda02a30$a401280a@.phx.gbl...
> We are migrating a browser based application developed
> with the Enterprise version to a server running the
> standard edition. There will be some development on the
> standard version before a new vresion of the application
> is deployed. Can anyone help me to understand what
> issues/problems we should look out for?
Showing posts with label based. Show all posts
Showing posts with label based. Show all posts
Friday, March 30, 2012
Monday, March 26, 2012
Migrating AS/400 DB2 to SQL Server
The client I'm working at right now is currently moving from their current
ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
doing so they are migrating 2 physical AS/400's with 4 business units (2 on
each 400) over to SYSPRO. They have moved one out of the four and a
preparing to move the the second. When migrating over to SYSPRO they only
moved the needed information to go live on the new system hence leaving years
of sales, orders, customer and product information.
So my question is there anything just blazingly important that I should know
when using DTS to pull all of this data over to SQL Server?
I know that the structure of the 400 DB2 isn't exactly the same as SQL
Server. From what I understand multiple Libraries make up a database in the
400. Each of those contain files and logicals. Files look to be the same as
a tables and logicals look to be the same as views.
Thx
You're pretty much on the ball with the file vs table and logical vs view
deal, for what you're trying to do, they're affectively equivalent. I ran
into some trouble with this in a past life, though. There was a lot of
trailing white space in the character fields I pulled out of the 400. It was
a different ERP, and it may have been human error causing it (I'm no DB2
guru), but I wound up having to RTRIM a lot of stuff on it's way over. Only
issue I ran into, though.
"Chris Stevenson" wrote:
> The client I'm working at right now is currently moving from their current
> ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
> doing so they are migrating 2 physical AS/400's with 4 business units (2 on
> each 400) over to SYSPRO. They have moved one out of the four and a
> preparing to move the the second. When migrating over to SYSPRO they only
> moved the needed information to go live on the new system hence leaving years
> of sales, orders, customer and product information.
> So my question is there anything just blazingly important that I should know
> when using DTS to pull all of this data over to SQL Server?
> I know that the structure of the 400 DB2 isn't exactly the same as SQL
> Server. From what I understand multiple Libraries make up a database in the
> 400. Each of those contain files and logicals. Files look to be the same as
> a tables and logicals look to be the same as views.
> Thx
ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
doing so they are migrating 2 physical AS/400's with 4 business units (2 on
each 400) over to SYSPRO. They have moved one out of the four and a
preparing to move the the second. When migrating over to SYSPRO they only
moved the needed information to go live on the new system hence leaving years
of sales, orders, customer and product information.
So my question is there anything just blazingly important that I should know
when using DTS to pull all of this data over to SQL Server?
I know that the structure of the 400 DB2 isn't exactly the same as SQL
Server. From what I understand multiple Libraries make up a database in the
400. Each of those contain files and logicals. Files look to be the same as
a tables and logicals look to be the same as views.
Thx
You're pretty much on the ball with the file vs table and logical vs view
deal, for what you're trying to do, they're affectively equivalent. I ran
into some trouble with this in a past life, though. There was a lot of
trailing white space in the character fields I pulled out of the 400. It was
a different ERP, and it may have been human error causing it (I'm no DB2
guru), but I wound up having to RTRIM a lot of stuff on it's way over. Only
issue I ran into, though.
"Chris Stevenson" wrote:
> The client I'm working at right now is currently moving from their current
> ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
> doing so they are migrating 2 physical AS/400's with 4 business units (2 on
> each 400) over to SYSPRO. They have moved one out of the four and a
> preparing to move the the second. When migrating over to SYSPRO they only
> moved the needed information to go live on the new system hence leaving years
> of sales, orders, customer and product information.
> So my question is there anything just blazingly important that I should know
> when using DTS to pull all of this data over to SQL Server?
> I know that the structure of the 400 DB2 isn't exactly the same as SQL
> Server. From what I understand multiple Libraries make up a database in the
> 400. Each of those contain files and logicals. Files look to be the same as
> a tables and logicals look to be the same as views.
> Thx
Migrating AS/400 DB2 to SQL Server
The client I'm working at right now is currently moving from their current
ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
doing so they are migrating 2 physical AS/400's with 4 business units (2 on
each 400) over to SYSPRO. They have moved one out of the four and a
preparing to move the the second. When migrating over to SYSPRO they only
moved the needed information to go live on the new system hence leaving years
of sales, orders, customer and product information.
So my question is there anything just blazingly important that I should know
when using DTS to pull all of this data over to SQL Server?
I know that the structure of the 400 DB2 isn't exactly the same as SQL
Server. From what I understand multiple Libraries make up a database in the
400. Each of those contain files and logicals. Files look to be the same as
a tables and logicals look to be the same as views.
ThxYou're pretty much on the ball with the file vs table and logical vs view
deal, for what you're trying to do, they're affectively equivalent. I ran
into some trouble with this in a past life, though. There was a lot of
trailing white space in the character fields I pulled out of the 400. It was
a different ERP, and it may have been human error causing it (I'm no DB2
guru), but I wound up having to RTRIM a lot of stuff on it's way over. Only
issue I ran into, though.
"Chris Stevenson" wrote:
> The client I'm working at right now is currently moving from their current
> ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
> doing so they are migrating 2 physical AS/400's with 4 business units (2 on
> each 400) over to SYSPRO. They have moved one out of the four and a
> preparing to move the the second. When migrating over to SYSPRO they only
> moved the needed information to go live on the new system hence leaving years
> of sales, orders, customer and product information.
> So my question is there anything just blazingly important that I should know
> when using DTS to pull all of this data over to SQL Server?
> I know that the structure of the 400 DB2 isn't exactly the same as SQL
> Server. From what I understand multiple Libraries make up a database in the
> 400. Each of those contain files and logicals. Files look to be the same as
> a tables and logicals look to be the same as views.
> Thx
ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
doing so they are migrating 2 physical AS/400's with 4 business units (2 on
each 400) over to SYSPRO. They have moved one out of the four and a
preparing to move the the second. When migrating over to SYSPRO they only
moved the needed information to go live on the new system hence leaving years
of sales, orders, customer and product information.
So my question is there anything just blazingly important that I should know
when using DTS to pull all of this data over to SQL Server?
I know that the structure of the 400 DB2 isn't exactly the same as SQL
Server. From what I understand multiple Libraries make up a database in the
400. Each of those contain files and logicals. Files look to be the same as
a tables and logicals look to be the same as views.
ThxYou're pretty much on the ball with the file vs table and logical vs view
deal, for what you're trying to do, they're affectively equivalent. I ran
into some trouble with this in a past life, though. There was a lot of
trailing white space in the character fields I pulled out of the 400. It was
a different ERP, and it may have been human error causing it (I'm no DB2
guru), but I wound up having to RTRIM a lot of stuff on it's way over. Only
issue I ran into, though.
"Chris Stevenson" wrote:
> The client I'm working at right now is currently moving from their current
> ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
> doing so they are migrating 2 physical AS/400's with 4 business units (2 on
> each 400) over to SYSPRO. They have moved one out of the four and a
> preparing to move the the second. When migrating over to SYSPRO they only
> moved the needed information to go live on the new system hence leaving years
> of sales, orders, customer and product information.
> So my question is there anything just blazingly important that I should know
> when using DTS to pull all of this data over to SQL Server?
> I know that the structure of the 400 DB2 isn't exactly the same as SQL
> Server. From what I understand multiple Libraries make up a database in the
> 400. Each of those contain files and logicals. Files look to be the same as
> a tables and logicals look to be the same as views.
> Thx
Migrating AS/400 DB2 to SQL Server
The client I'm working at right now is currently moving from their current
ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
doing so they are migrating 2 physical AS/400's with 4 business units (2 on
each 400) over to SYSPRO. They have moved one out of the four and a
preparing to move the the second. When migrating over to SYSPRO they only
moved the needed information to go live on the new system hence leaving year
s
of sales, orders, customer and product information.
So my question is there anything just blazingly important that I should know
when using DTS to pull all of this data over to SQL Server?
I know that the structure of the 400 DB2 isn't exactly the same as SQL
Server. From what I understand multiple Libraries make up a database in the
400. Each of those contain files and logicals. Files look to be the same a
s
a tables and logicals look to be the same as views.
ThxYou're pretty much on the ball with the file vs table and logical vs view
deal, for what you're trying to do, they're affectively equivalent. I ran
into some trouble with this in a past life, though. There was a lot of
trailing white space in the character fields I pulled out of the 400. It wa
s
a different ERP, and it may have been human error causing it (I'm no DB2
guru), but I wound up having to RTRIM a lot of stuff on it's way over. Only
issue I ran into, though.
"Chris Stevenson" wrote:
> The client I'm working at right now is currently moving from their current
> ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
> doing so they are migrating 2 physical AS/400's with 4 business units (2 o
n
> each 400) over to SYSPRO. They have moved one out of the four and a
> preparing to move the the second. When migrating over to SYSPRO they only
> moved the needed information to go live on the new system hence leaving ye
ars
> of sales, orders, customer and product information.
> So my question is there anything just blazingly important that I should kn
ow
> when using DTS to pull all of this data over to SQL Server?
> I know that the structure of the 400 DB2 isn't exactly the same as SQL
> Server. From what I understand multiple Libraries make up a database in t
he
> 400. Each of those contain files and logicals. Files look to be the same
as
> a tables and logicals look to be the same as views.
> Thx
ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
doing so they are migrating 2 physical AS/400's with 4 business units (2 on
each 400) over to SYSPRO. They have moved one out of the four and a
preparing to move the the second. When migrating over to SYSPRO they only
moved the needed information to go live on the new system hence leaving year
s
of sales, orders, customer and product information.
So my question is there anything just blazingly important that I should know
when using DTS to pull all of this data over to SQL Server?
I know that the structure of the 400 DB2 isn't exactly the same as SQL
Server. From what I understand multiple Libraries make up a database in the
400. Each of those contain files and logicals. Files look to be the same a
s
a tables and logicals look to be the same as views.
ThxYou're pretty much on the ball with the file vs table and logical vs view
deal, for what you're trying to do, they're affectively equivalent. I ran
into some trouble with this in a past life, though. There was a lot of
trailing white space in the character fields I pulled out of the 400. It wa
s
a different ERP, and it may have been human error causing it (I'm no DB2
guru), but I wound up having to RTRIM a lot of stuff on it's way over. Only
issue I ran into, though.
"Chris Stevenson" wrote:
> The client I'm working at right now is currently moving from their current
> ERP contained on AS/400 to a MS SQL Server based ERP known as SYSPRO. In
> doing so they are migrating 2 physical AS/400's with 4 business units (2 o
n
> each 400) over to SYSPRO. They have moved one out of the four and a
> preparing to move the the second. When migrating over to SYSPRO they only
> moved the needed information to go live on the new system hence leaving ye
ars
> of sales, orders, customer and product information.
> So my question is there anything just blazingly important that I should kn
ow
> when using DTS to pull all of this data over to SQL Server?
> I know that the structure of the 400 DB2 isn't exactly the same as SQL
> Server. From what I understand multiple Libraries make up a database in t
he
> 400. Each of those contain files and logicals. Files look to be the same
as
> a tables and logicals look to be the same as views.
> Thx
Monday, March 12, 2012
Middle Search Support
Some of the databases that I inherited contain search that are based on finding a string anywhere within a last name such as:
WHERE lastName like '%smith%'
It is desired that each of these names be returned:
Smith
Smithson
Nesmith
What is presently done is that updates to the last name fields trigger that substrings of the last name be sent off into a substring table wtih retention of no 2-char substrings. For these three last names the following would be kept:
(1) Smith, (2) mith, (3) ith and (4) th
(1) Smithson, (2) mithson, (3) ithson, ..., (n) on
(1) Nesmith, (2) esmith, (3) smith, ... (n) th
The where now becomes
WHERE lastNameSub like 'smith%'
This seems to make the search routine by last name faster. I would like to improve on this if I can. Suggestions?
Dave
Hello Dave,
I'm afraid you can't within the core engine alone. Obviously a good indexing strategy will help you, but if we're talking about improving the substring/like search on a character column, apart from indexing, you don't have many options.
As you've discovered, using 'smith%' is much faster then '%smith%' as the optimiser has the opportunity to perform an index scan in the first instance - it does not in the second.
If you are performing a lot of these types of searches, I would look at full-text search:
http://www.databasejournal.com/features/mssql/article.php/3441981
http://www.sql-server-performance.com/tb_search_optimization.asp
Cheers,
Rob
Friday, March 9, 2012
Microsoft.Reporting.WebForms.ReportViewer does not contain a definition for Reset
Hi everyone I developed a web form with a report viewer. I change the report datasource and report path based on user input. Before i do anything on the report i first reset it with this line:
rvWaitTime.Reset();
And then set the parameters, datasources, etc. It works fine on my dev machine: Windows Vista with .NET 2.0 installed (.NET 3.0 is installed as well). When I move the code to the production box: Windows Server 2003 with .NET 2.0 and 3.0 installed i get this error:
'Microsoft.Reporting.WebForms.ReportViewer' does not contain a definition for 'Reset'
and of course it fails on the line of code mentioned above.
Any ideas?
Who would have thought that you needed a seperate installation for a control that comes built in with VS 2005? I finally solved the problem. I needed to install theMicrosoft Report Viewer Redistributable 2005 SP1 (Full Installation) on my server and now everything works like a charm!
Subscribe to:
Comments (Atom)