Showing posts with label records. Show all posts
Showing posts with label records. Show all posts

Tuesday, March 27, 2012

Database capacity

Hi,

I’m working in a DWH project the source system have data from passed 30 years and the total number of records from the source system is 10 million.

I’m need to do the estimation for the data base for the up coming 10 years of data.

As I can predict that the 30 year of data is 10 million then expected data for 10 years would not be more then 3 million.

The ETL tool I’m using is SQL Server Integration services and the reporting tool is Business Objects.

Can any one guide me on the implementation plan, meanmemory taken for ETL jobs (As SSIS use large amount of memory) database and business objects.

Sheikh

A good place to start is this link http://www.dmreview.com/article_sub.cfm?articleId=1048082

In talks in general about Capacity Planning.

Some basic things I would say -- almost a must have for a Datawarehouse

1) 64 Bit Environment -- you can use more than 4 GB of Memory in here (well you can use more than 4 GB in a 32 bit -- but 64 bit is better, especially if you can afford it).

2) Min of 8 GB of RAM. (considering you do not have more than 15 Million Rows).

3) Obviously -- enough Hard DIsk space for your DW.

4) A Good Disk Subsytem.

But a lot depends on your usage pattern and what you are trying to achieve. Ultimately it will all come down to cost vs benefit.

|||Thank you for the helpfull post.

Database blocking

We have several large reports that access tables with millions of records. In
such cases we expect that blocking may occur; however, the report server will
perform specific commands that lock the database as well. These commands
include UPDATE,DELETE,AWAITING COMMAND. We have a program running to monitor
blocking on our databases so we are able to see when the blocking occurs but
we are unable to find the cause of this problem. The program allows us to see
when a user is causing blocking by running a large report or performing some
other action. The blocking that concerns us is not generated by a user but by
the Report Server itself. It appears that the Report Server performs these
actions after a large report is run or after a report is deployed to the
server.I forgot to ask our question. Does anyone know what process is causing the
blocking and what can we do about it?|||Are you sure this activity you are seeing isn't against its own database.
Report server uses its own database extensively but that should not affect
the database you are reporting against. I go against 1-10 million row tables
all the time, I have an 80 million row table as well. Report server has
never caused a problem with any other application going against the
database. There is no way that Report server is doing an update or delete
against your database. The reports run under the credentials you apply them.
The credentials I use is a readonly account on SQL Server (and Sybase, I
report against both).
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Clark Kent" <ClarkKent@.discussions.microsoft.com> wrote in message
news:F583BA12-3E2C-4C65-A9B5-291FDCEAB3DD@.microsoft.com...
> We have several large reports that access tables with millions of records.
> In
> such cases we expect that blocking may occur; however, the report server
> will
> perform specific commands that lock the database as well. These commands
> include UPDATE,DELETE,AWAITING COMMAND. We have a program running to
> monitor
> blocking on our databases so we are able to see when the blocking occurs
> but
> we are unable to find the cause of this problem. The program allows us to
> see
> when a user is causing blocking by running a large report or performing
> some
> other action. The blocking that concerns us is not generated by a user but
> by
> the Report Server itself. It appears that the Report Server performs these
> actions after a large report is run or after a report is deployed to the
> server.|||Our production databases are on the same server as the report server so when
the report server causes blocking in the master database we are getting
blocking issues server-wide. Is there a way to fine tune the processes that
are blocking or schedule them to run during down times?
"Bruce L-C [MVP]" wrote:
> Are you sure this activity you are seeing isn't against its own database.
> Report server uses its own database extensively but that should not affect
> the database you are reporting against. I go against 1-10 million row tables
> all the time, I have an 80 million row table as well. Report server has
> never caused a problem with any other application going against the
> database. There is no way that Report server is doing an update or delete
> against your database. The reports run under the credentials you apply them.
> The credentials I use is a readonly account on SQL Server (and Sybase, I
> report against both).
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Clark Kent" <ClarkKent@.discussions.microsoft.com> wrote in message
> news:F583BA12-3E2C-4C65-A9B5-291FDCEAB3DD@.microsoft.com...
> > We have several large reports that access tables with millions of records.
> > In
> > such cases we expect that blocking may occur; however, the report server
> > will
> > perform specific commands that lock the database as well. These commands
> > include UPDATE,DELETE,AWAITING COMMAND. We have a program running to
> > monitor
> > blocking on our databases so we are able to see when the blocking occurs
> > but
> > we are unable to find the cause of this problem. The program allows us to
> > see
> > when a user is causing blocking by running a large report or performing
> > some
> > other action. The blocking that concerns us is not generated by a user but
> > by
> > the Report Server itself. It appears that the Report Server performs these
> > actions after a large report is run or after a report is deployed to the
> > server.
>
>|||"Bruce L-C [MVP]" wrote:
> Are you sure this activity you are seeing isn't against its own database.
> Report server uses its own database extensively but that should not affect
> the database you are reporting against. I go against 1-10 million row tables
> all the time, I have an 80 million row table as well. Report server has
> never caused a problem with any other application going against the
> database. There is no way that Report server is doing an update or delete
> against your database. The reports run under the credentials you apply them.
> The credentials I use is a readonly account on SQL Server (and Sybase, I
> report against both).
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Clark Kent" <ClarkKent@.discussions.microsoft.com> wrote in message
> news:F583BA12-3E2C-4C65-A9B5-291FDCEAB3DD@.microsoft.com...
> > We have several large reports that access tables with millions of records.
> > In
> > such cases we expect that blocking may occur; however, the report server
> > will
> > perform specific commands that lock the database as well. These commands
> > include UPDATE,DELETE,AWAITING COMMAND. We have a program running to
> > monitor
> > blocking on our databases so we are able to see when the blocking occurs
> > but
> > we are unable to find the cause of this problem. The program allows us to
> > see
> > when a user is causing blocking by running a large report or performing
> > some
> > other action. The blocking that concerns us is not generated by a user but
> > by
> > the Report Server itself. It appears that the Report Server performs these
> > actions after a large report is run or after a report is deployed to the
> > server.
>
>|||Let me rephrase the whole scenario.
All of our production databases are on the same server as our Reporting
Services database. The reporting services database is causing blocking that
we monitor via our app. Blocking occurs at random times during the day that
do not directly corresponding to pulling a report. For example, if I deploy a
new report to the server, I may get a blocking indicator that the reporting
server is AWAITING COMMAND, or UPDATE. I have had blocking issues when
clicking the Print Preview button as well. It is not necessarily the report
data that is causing the blocking as I mentioned earlier, but it is some
process that the Reporting Services database is performing.
Without getting to far into the Reporting Services database structure, can
anyone tell me what processes are being performed by Reporting Services that
could cause this blocking? Does the database create a cache when you deploy a
new report or print preview a report?
Anyone? Anyone? Beuhler?
If no one knows, then we can live with it; however, it would be nice to
eliminate the blocking altogether.
"BootieNH" wrote:
>
> "Bruce L-C [MVP]" wrote:
> > Are you sure this activity you are seeing isn't against its own database.
> > Report server uses its own database extensively but that should not affect
> > the database you are reporting against. I go against 1-10 million row tables
> > all the time, I have an 80 million row table as well. Report server has
> > never caused a problem with any other application going against the
> > database. There is no way that Report server is doing an update or delete
> > against your database. The reports run under the credentials you apply them.
> > The credentials I use is a readonly account on SQL Server (and Sybase, I
> > report against both).
> >
> >
> > --
> > Bruce Loehle-Conger
> > MVP SQL Server Reporting Services
> >
> > "Clark Kent" <ClarkKent@.discussions.microsoft.com> wrote in message
> > news:F583BA12-3E2C-4C65-A9B5-291FDCEAB3DD@.microsoft.com...
> > > We have several large reports that access tables with millions of records.
> > > In
> > > such cases we expect that blocking may occur; however, the report server
> > > will
> > > perform specific commands that lock the database as well. These commands
> > > include UPDATE,DELETE,AWAITING COMMAND. We have a program running to
> > > monitor
> > > blocking on our databases so we are able to see when the blocking occurs
> > > but
> > > we are unable to find the cause of this problem. The program allows us to
> > > see
> > > when a user is causing blocking by running a large report or performing
> > > some
> > > other action. The blocking that concerns us is not generated by a user but
> > > by
> > > the Report Server itself. It appears that the Report Server performs these
> > > actions after a large report is run or after a report is deployed to the
> > > server.
> >
> >
> >|||Bruce, excuse me for hijacking this thread, but I am currently
troubleshooting a deadlock problem occurring between our application and
ReportServer. I've isolated that our application process, which is invoking
a stored procedure and passing XML to perform either an INSERT or UPDATE, is
deadlocking with a report SELECT query against a view of that database.
Examining the locking detail shows that our UPDATE query is holding an
exclusive intent lock (LCK_M_IX) on the table [inside a transaction] in order
to perform the update, while Report Services is holding a shared lock
(LCK_M_S) on a SELECT of a view. These locks are incompatible, so a deadlock
occurs, and the lower priority transaction is terminated. At least that's my
understanding. I'm wondering how I need to avoid this problem. I'm
surprised I'm not seeing more threads on this topic, I would have expected
more people to be experiencing this. Is it necessary to configure a lock
timeout for SQL Server to avoid this issue? Thanks!
"Bruce L-C [MVP]" wrote:
> Are you sure this activity you are seeing isn't against its own database.
> Report server uses its own database extensively but that should not affect
> the database you are reporting against. I go against 1-10 million row tables
> all the time, I have an 80 million row table as well. Report server has
> never caused a problem with any other application going against the
> database. There is no way that Report server is doing an update or delete
> against your database. The reports run under the credentials you apply them.
> The credentials I use is a readonly account on SQL Server (and Sybase, I
> report against both).
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Clark Kent" <ClarkKent@.discussions.microsoft.com> wrote in message
> news:F583BA12-3E2C-4C65-A9B5-291FDCEAB3DD@.microsoft.com...
> > We have several large reports that access tables with millions of records.
> > In
> > such cases we expect that blocking may occur; however, the report server
> > will
> > perform specific commands that lock the database as well. These commands
> > include UPDATE,DELETE,AWAITING COMMAND. We have a program running to
> > monitor
> > blocking on our databases so we are able to see when the blocking occurs
> > but
> > we are unable to find the cause of this problem. The program allows us to
> > see
> > when a user is causing blocking by running a large report or performing
> > some
> > other action. The blocking that concerns us is not generated by a user but
> > by
> > the Report Server itself. It appears that the Report Server performs these
> > actions after a large report is run or after a report is deployed to the
> > server.
>
>|||Clark, I've spent the last 3 days muddling through extensive locking detail
trying to debug my issue. I think Bruce was implying that Report Server is
doing tons of stuff in its own database, and that shouldn't conflict with
your database. And of course your reports would only be running SELECT
queries. But I'm currently debugging locking issues with exactly this
scenario. Have you looked in detail at the SPIDs of the blocking? Is it
causing behavior problems? I'm trying to figure this out too, and it's not
fun.
"Clark Kent" wrote:
> Let me rephrase the whole scenario.
> All of our production databases are on the same server as our Reporting
> Services database. The reporting services database is causing blocking that
> we monitor via our app. Blocking occurs at random times during the day that
> do not directly corresponding to pulling a report. For example, if I deploy a
> new report to the server, I may get a blocking indicator that the reporting
> server is AWAITING COMMAND, or UPDATE. I have had blocking issues when
> clicking the Print Preview button as well. It is not necessarily the report
> data that is causing the blocking as I mentioned earlier, but it is some
> process that the Reporting Services database is performing.
> Without getting to far into the Reporting Services database structure, can
> anyone tell me what processes are being performed by Reporting Services that
> could cause this blocking? Does the database create a cache when you deploy a
> new report or print preview a report?
> Anyone? Anyone? Beuhler?
> If no one knows, then we can live with it; however, it would be nice to
> eliminate the blocking altogether.
> "BootieNH" wrote:
> >
> >
> > "Bruce L-C [MVP]" wrote:
> >
> > > Are you sure this activity you are seeing isn't against its own database.
> > > Report server uses its own database extensively but that should not affect
> > > the database you are reporting against. I go against 1-10 million row tables
> > > all the time, I have an 80 million row table as well. Report server has
> > > never caused a problem with any other application going against the
> > > database. There is no way that Report server is doing an update or delete
> > > against your database. The reports run under the credentials you apply them.
> > > The credentials I use is a readonly account on SQL Server (and Sybase, I
> > > report against both).
> > >
> > >
> > > --
> > > Bruce Loehle-Conger
> > > MVP SQL Server Reporting Services
> > >
> > > "Clark Kent" <ClarkKent@.discussions.microsoft.com> wrote in message
> > > news:F583BA12-3E2C-4C65-A9B5-291FDCEAB3DD@.microsoft.com...
> > > > We have several large reports that access tables with millions of records.
> > > > In
> > > > such cases we expect that blocking may occur; however, the report server
> > > > will
> > > > perform specific commands that lock the database as well. These commands
> > > > include UPDATE,DELETE,AWAITING COMMAND. We have a program running to
> > > > monitor
> > > > blocking on our databases so we are able to see when the blocking occurs
> > > > but
> > > > we are unable to find the cause of this problem. The program allows us to
> > > > see
> > > > when a user is causing blocking by running a large report or performing
> > > > some
> > > > other action. The blocking that concerns us is not generated by a user but
> > > > by
> > > > the Report Server itself. It appears that the Report Server performs these
> > > > actions after a large report is run or after a report is deployed to the
> > > > server.
> > >
> > >
> > >|||I was hoping that I could avoid getting into the spid detail, but I will look
into it further. As for interference, I can't recall specific instances of
non-reporting service transactions being blocked, but I am pretty sure it has
happened. I will have to pay closer attention to it to make sure. I was
hoping to find a quick answer to all this, but it doesn't look like that will
happen soon. It appears that reporting services is blocking itself the
majority of the time. I will let you know if I find out anything useful.
"BootieNH" wrote:
> Clark, I've spent the last 3 days muddling through extensive locking detail
> trying to debug my issue. I think Bruce was implying that Report Server is
> doing tons of stuff in its own database, and that shouldn't conflict with
> your database. And of course your reports would only be running SELECT
> queries. But I'm currently debugging locking issues with exactly this
> scenario. Have you looked in detail at the SPIDs of the blocking? Is it
> causing behavior problems? I'm trying to figure this out too, and it's not
> fun.
> "Clark Kent" wrote:
> > Let me rephrase the whole scenario.
> >
> > All of our production databases are on the same server as our Reporting
> > Services database. The reporting services database is causing blocking that
> > we monitor via our app. Blocking occurs at random times during the day that
> > do not directly corresponding to pulling a report. For example, if I deploy a
> > new report to the server, I may get a blocking indicator that the reporting
> > server is AWAITING COMMAND, or UPDATE. I have had blocking issues when
> > clicking the Print Preview button as well. It is not necessarily the report
> > data that is causing the blocking as I mentioned earlier, but it is some
> > process that the Reporting Services database is performing.
> >
> > Without getting to far into the Reporting Services database structure, can
> > anyone tell me what processes are being performed by Reporting Services that
> > could cause this blocking? Does the database create a cache when you deploy a
> > new report or print preview a report?
> >
> > Anyone? Anyone? Beuhler?
> >
> > If no one knows, then we can live with it; however, it would be nice to
> > eliminate the blocking altogether.
> >
> > "BootieNH" wrote:
> >
> > >
> > >
> > > "Bruce L-C [MVP]" wrote:
> > >
> > > > Are you sure this activity you are seeing isn't against its own database.
> > > > Report server uses its own database extensively but that should not affect
> > > > the database you are reporting against. I go against 1-10 million row tables
> > > > all the time, I have an 80 million row table as well. Report server has
> > > > never caused a problem with any other application going against the
> > > > database. There is no way that Report server is doing an update or delete
> > > > against your database. The reports run under the credentials you apply them.
> > > > The credentials I use is a readonly account on SQL Server (and Sybase, I
> > > > report against both).
> > > >
> > > >
> > > > --
> > > > Bruce Loehle-Conger
> > > > MVP SQL Server Reporting Services
> > > >
> > > > "Clark Kent" <ClarkKent@.discussions.microsoft.com> wrote in message
> > > > news:F583BA12-3E2C-4C65-A9B5-291FDCEAB3DD@.microsoft.com...
> > > > > We have several large reports that access tables with millions of records.
> > > > > In
> > > > > such cases we expect that blocking may occur; however, the report server
> > > > > will
> > > > > perform specific commands that lock the database as well. These commands
> > > > > include UPDATE,DELETE,AWAITING COMMAND. We have a program running to
> > > > > monitor
> > > > > blocking on our databases so we are able to see when the blocking occurs
> > > > > but
> > > > > we are unable to find the cause of this problem. The program allows us to
> > > > > see
> > > > > when a user is causing blocking by running a large report or performing
> > > > > some
> > > > > other action. The blocking that concerns us is not generated by a user but
> > > > > by
> > > > > the Report Server itself. It appears that the Report Server performs these
> > > > > actions after a large report is run or after a report is deployed to the
> > > > > server.
> > > >
> > > >
> > > >|||This is really not a RS issue but a generic database question. So I posted
your question on the private SQL Server MVP newsgroup and got this answer
back for you:
>>>>>>>>>
Don't use lock timeouts or you will end up with broken transactions. I
suggest using the NOLOCK hint on the select query. You may end up with
imperfect data, but this may not be critical depending on your application
and report. For example, if a weekly call center activity report is off by
one or two calls, it really doesn't matter.
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
>>>>>>>>>>
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"BootieNH" <BootieNH@.discussions.microsoft.com> wrote in message
news:9B48D882-7479-4F90-BC8A-5D7308232496@.microsoft.com...
> Bruce, excuse me for hijacking this thread, but I am currently
> troubleshooting a deadlock problem occurring between our application and
> ReportServer. I've isolated that our application process, which is
> invoking
> a stored procedure and passing XML to perform either an INSERT or UPDATE,
> is
> deadlocking with a report SELECT query against a view of that database.
> Examining the locking detail shows that our UPDATE query is holding an
> exclusive intent lock (LCK_M_IX) on the table [inside a transaction] in
> order
> to perform the update, while Report Services is holding a shared lock
> (LCK_M_S) on a SELECT of a view. These locks are incompatible, so a
> deadlock
> occurs, and the lower priority transaction is terminated. At least that's
> my
> understanding. I'm wondering how I need to avoid this problem. I'm
> surprised I'm not seeing more threads on this topic, I would have expected
> more people to be experiencing this. Is it necessary to configure a lock
> timeout for SQL Server to avoid this issue? Thanks!
> "Bruce L-C [MVP]" wrote:
>> Are you sure this activity you are seeing isn't against its own database.
>> Report server uses its own database extensively but that should not
>> affect
>> the database you are reporting against. I go against 1-10 million row
>> tables
>> all the time, I have an 80 million row table as well. Report server has
>> never caused a problem with any other application going against the
>> database. There is no way that Report server is doing an update or delete
>> against your database. The reports run under the credentials you apply
>> them.
>> The credentials I use is a readonly account on SQL Server (and Sybase, I
>> report against both).
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Clark Kent" <ClarkKent@.discussions.microsoft.com> wrote in message
>> news:F583BA12-3E2C-4C65-A9B5-291FDCEAB3DD@.microsoft.com...
>> > We have several large reports that access tables with millions of
>> > records.
>> > In
>> > such cases we expect that blocking may occur; however, the report
>> > server
>> > will
>> > perform specific commands that lock the database as well. These
>> > commands
>> > include UPDATE,DELETE,AWAITING COMMAND. We have a program running to
>> > monitor
>> > blocking on our databases so we are able to see when the blocking
>> > occurs
>> > but
>> > we are unable to find the cause of this problem. The program allows us
>> > to
>> > see
>> > when a user is causing blocking by running a large report or performing
>> > some
>> > other action. The blocking that concerns us is not generated by a user
>> > but
>> > by
>> > the Report Server itself. It appears that the Report Server performs
>> > these
>> > actions after a large report is run or after a report is deployed to
>> > the
>> > server.
>>sql

Sunday, March 11, 2012

Database Append

I would highly appreciate help to :
I have two databases that are of the same schema but in one-database-A the records are a bit older than the other database-B. I would lilke to sync the records from database-B to database-A appending the records to database-A. The schemas have constraints,primary keys and other defaults in common.

What is the best way to do this task? I tried to use DTS but it fails throwing error Primary key violations on the tables.

Thanks a lot for a good suggestion.
VinnieThis really depends on what other tables depend on this table. You will need to post any relationships/dependencies to this table. Also, define your constraints. How is the primary key generated/defined for both tables ?|||It is not one table but all tables in database. I can not drop or truncate the destination database table data as there may be student number child data in the source database tables that does not exist in old database. Do I have to write a script taking into consideration each table and it's dependencies or PK an FK and other constraints? That may take hell a lot of time to figure out. Any better suggestion than this thought is highly appreciated.|||What are some specific examples of the data that resides in both databases - what happens when you have 2 identical records in the same table in both databases - what is the relationship (or is there) of the data between the 2 databases (or do you just want to append all old data or do you want to reconcile) - how many parent-child relationships exist ?

These are not normally simple translations because the same primary key can exist in both databases/tables - if it does then you will have to translate the parent/child keys from the old to the new.|||Depending on your keys, you might be able to query against the new database and find where duplicate keys exist and generate new keys and cascade those new keys to the children. Then migrate all data from old to new - if that is your process.

Thursday, March 8, 2012

Database Acting Strange

MY DATABASE FOR SHOPPING CART IS ACTING STRANGE IT HAS AUTOMATICALLY DESTOYED ALL PRIMARY KEYS. AND HAS CREATED 4 DUPLICATE RECORDS FOR EACH RECORD SO AT THIS STAGE I HAVE AROUNG 15000 RECORDS IN EACH TABLE IT MEANS 15 TIMES 4 60000 RECORDS. CAN ANYONE UPDATEME WHY THIS HAS HAPPENED AND WHAT CAN BE DONE TO DELETE EXISTING DUPLICATES. I NEED FAST REPLY IN THIS MATTER AS THIS IS URGENT. IF POSSIBLE KINDLY WRITE QUERIES TRIGGERS FOR FUTURE PROBLEMS AS WELL AS THESE DAYS I AM SICK SO MY BRAIN AINT WORKING IN THIS MATTER. URGENT URGENT URGENT THANKS ALOT I HAVE PREVIOUSLY POSTED AND HAVE GOT A GOOD RESPONSE. AND HOPE A GOOD ONE AGAIN. ONE MORE THING IS THAT I HAVE A BACKUP HERE AT MY OFFICE SYSTEM IT ALSO HAS DONE THE SAMETHING. I MADE A NEW DATABASE AND TRYED TO IMPORT DATA WITH DISTINCT KEYWORD BUUT IT IS NOT COPYING IT AS WELL. URGENT RESPONSE REQUIRED IF ANYONE CAN DO.It's that damn Miracle thing againnn....I hate when that happens...

Who else has sa rights to the server?|||Computers are like dogs. They can sense fear. You need to stop panicking and find out exactly when this occured, what was running, who was logged in, what the last code changes implemented were, etc...
Standard problem solving mode.

SQL Server will not, of its own accord, drop keys and duplicate records. Someone or some code did this.|||...and if I could write queries and triggers for future problems I'd be a wealthy man.|||Originally posted by blindman
...and if I could write queries and triggers for future problems I'd be a wealthy man.

LOL

Still working on the AI_DBA module?|||Oh, I finished that months ago. Works like a charm. But if I release it, I'd be out of a job.

If someone invented a light bulb that never burned out, who would want to manufacture them?|||What does that module do?|||AI_DBA module automatically and flawlessly performs all Database Administration and Development duties without the need for high-priced talent. It's user inteface consists of a single button that says "OK". It senses the manner and duration of the keypress to intuitively analyze the user's intentions and create a complete Requirements Document based upon the user's subconcious needs rather than just what they SAY they want, and completes the task within and regardless of all the unreasonable restrictions placed upon it by a boss who "knows better". It's "I told you so" submodule has been completely removed to spare any egos, and if you have an internet connection it automatically logs into dbforums three times each day and answers all questions containing the text words "date" and "format".|||OK-OK, I got the drift :)|||Originally posted by blindman
AI_DBA module automatically and flawlessly performs all Database Administration and Development duties without the need for high-priced talent. It's user inteface consists of a single button that says "OK". It senses the manner and duration of the keypress to intuitively analyze the user's intentions and create a complete Requirements Document based upon the user's subconcious needs rather than just what they SAY they want, and completes the task within and regardless of all the unreasonable restrictions placed upon it by a boss who "knows better". It's "I told you so" submodule has been completely removed to spare any egos, and if you have an internet connection it automatically logs into dbforums three times each day and answers all questions containing the text words "date" and "format".

Yup...that's about right...

I like the subconcious part...

Wednesday, March 7, 2012

DataAdapter.Update updates zero records

I am having trouble getting an Update call to actually update records. The select statement is a stored procedure which is uses inner joins to link to property tables. The update, insert, and delete commands were generated by Visual Studio and only affect the primary table. So, to provide a simple example, I have a customer table with UID, Name, and LanguageID and a seperate table with LanguageID and LanguageDescription. The stored procedure can be used to populate a datagrid with all results (this works). The stored procedure also populates an edit page with one UID (this works). After the edit is completed, I attempt to update the dataset, which only has one row at this time, which shows that it has been modified. The Update modifies 0 rows and raises no exceptions. Is this because the update, insert, and delete statements do not match up one-to-one with the dataset? If so, what are my choices?I found the source of the problem. It was a result of a conflict elsewhere. So, if anyone else is trying to use a combination of stored procedures and normal sql queries, it will work fine, even if the statements do not match up perfectly with the dataset. The queries simply need to meet any requirements of the database.

Saturday, February 25, 2012

Data/records in other languages

Hi,

Can the English version of Sql Server (or other DBMSs) store data/records in
other languages (e.g. French, Chinese, etc.) or
do you have to use the French version of Sql Server to store French data?

Where can I go to read more on this?

Thanks.
Eric"Eric" <ericd_@.hotmail.com> wrote in message news:<Gpjjb.3561$Z_2.317631@.news20.bellglobal.com>...
> Hi,
> Can the English version of Sql Server (or other DBMSs) store data/records in
> other languages (e.g. French, Chinese, etc.) or
> do you have to use the French version of Sql Server to store French data?
> Where can I go to read more on this?
> Thanks.
> Eric

You can use Unicode data types (nchar, nvarchar, ntext) to store
Unicode data, and it doesn't matter what language your version of
MSSQL is. You can get more information in Books Online in the sections
on "Using Unicode Data" and "Collations".

Simon

Friday, February 24, 2012

Data Validation Challenge

We have data migration process that transfers around 450 million records from
one DB to Another DB. There is a validation that takes place for the migrated
data that is time consuming (few days). The following validations takes place
on migrated data
NULL check
Length Check
Numeric Precision Check
So its looping through 450(rows) million * 30 (columns) times. so it takes
forever to complete the validation process and moreover the space
requirements also growing exponentially :-(. I would like to know is there a
better approach for validation of this kind. we are planning to try partition
approach. If there is any better way please help with your recommendations.
Regards,
Murali
Which tool are you using?
"Murali" wrote:

> We have data migration process that transfers around 450 million records from
> one DB to Another DB. There is a validation that takes place for the migrated
> data that is time consuming (few days). The following validations takes place
> on migrated data
> NULL check
> Length Check
> Numeric Precision Check
> So its looping through 450(rows) million * 30 (columns) times. so it takes
> forever to complete the validation process and moreover the space
> requirements also growing exponentially :-(. I would like to know is there a
> better approach for validation of this kind. we are planning to try partition
> approach. If there is any better way please help with your recommendations.
> Regards,
> Murali
>

Data Validation Challenge

We have data migration process that transfers around 450 million records fro
m
one DB to Another DB. There is a validation that takes place for the migrate
d
data that is time consuming (few days). The following validations takes plac
e
on migrated data
NULL check
Length Check
Numeric Precision Check
So its looping through 450(rows) million * 30 (columns) times. so it takes
forever to complete the validation process and moreover the space
requirements also growing exponentially :-(. I would like to know is there a
better approach for validation of this kind. we are planning to try partitio
n
approach. If there is any better way please help with your recommendations.
Regards,
MuraliWhich tool are you using?
"Murali" wrote:

> We have data migration process that transfers around 450 million records f
rom
> one DB to Another DB. There is a validation that takes place for the migra
ted
> data that is time consuming (few days). The following validations takes pl
ace
> on migrated data
> NULL check
> Length Check
> Numeric Precision Check
> So its looping through 450(rows) million * 30 (columns) times. so it takes
> forever to complete the validation process and moreover the space
> requirements also growing exponentially :-(. I would like to know is there
a
> better approach for validation of this kind. we are planning to try partit
ion
> approach. If there is any better way please help with your recommendations
.
> Regards,
> Murali
>

Sunday, February 19, 2012

Data type mismatch in criteria expresioin

Hi again, I'm having problems with an insert record page to insert records into a msaccess database via sql and dreamweaver mx.asp pages.

There are four date fields that can be entered (all not required), but it keep getting the

ERROR;Microsoft][ODBC Microsoft Access Driver] Data type mismatch in criteria expression.

from my documentation there seems to be a known problem with msaccess and update/insert server behaviours....

Has anyone managed to overcome this issue, and if so, how ??

thanks for your help...That may be because of the Date format on the access database.
Try to insert the date in this format:
aaaa-mm-dd

______________
Paulo Gonalves|||thanks heaps...I actually got it sorted about 20 minutes before I read your reply...and you were right...I had the msaccess date formats set to an input mask that I don't think dreamweaver took a liking to...

cheers.