OpenXML Identity Insert: opinions

Showing posts with label opinions. Show all posts

Friday, March 9, 2012

Opinons on using Delete then BULK INSERT

Hi. Just looking for your opinions on a technique I have seen for using BULK
INSERT. It reads through the flat file first deleting rows in the target
table that if finds. It then issues the BULK INSERT command on the same flat
file. This has the effect of doing an insert or update.
The DBA reports that the tables tend to become more fragmented because of
the deletes rather than using update.
Are there any pitfalls to this approach? Does it sound OK?
Are there other approaches other than Transact SQL for inserting or updating
large amounts of flat file data?
Thanks!!
McG

y
[url]http://mcg

y.blogspot.com[/url]"McG

y" <anon@.anon.com> wrote in message
news:eudcIdGPGHA.3984@.TK2MSFTNGP14.phx.gbl...
> Hi. Just looking for your opinions on a technique I have seen for using
> BULK INSERT. It reads through the flat file first deleting rows in the
> target table that if finds. It then issues the BULK INSERT command on the
> same flat file. This has the effect of doing an insert or update.
> The DBA reports that the tables tend to become more fragmented because of
> the deletes rather than using update.
> Are there any pitfalls to this approach? Does it sound OK?
> Are there other approaches other than Transact SQL for inserting or
> updating large amounts of flat file data?
> Thanks!!
> --
> McG

y
> [url]http://mcg

y.blogspot.com[/url]
>
>
It depends on how big the tables are and how big the flat file is.
Personally, I would probably BULK INSERT the flat file into a working table
first. Then using a chunking method, I would update/insert about 10,000
rows at a time until the task completed. This has the advantage of letting
SQL Server do what it does best using SET theory for determining updates and
inserts, but also doing it in small enough chunks that other processing can
continue with only slight interruption.
Just my .02
Rick Sawtell
MCT, MCSD, MCDBA|||Thanks for the pointer Rick.
McG

y
[url]http://mcg

y.blogspot.com[/url]
"Rick Sawtell" <Quickening@.msn.com> wrote in message
news:%23pxvSgGPGHA.1124@.TK2MSFTNGP10.phx.gbl...
> "McG

y" <anon@.anon.com> wrote in message
> news:eudcIdGPGHA.3984@.TK2MSFTNGP14.phx.gbl...
> It depends on how big the tables are and how big the flat file is.
> Personally, I would probably BULK INSERT the flat file into a working
> table first. Then using a chunking method, I would update/insert about
> 10,000 rows at a time until the task completed. This has the advantage of
> letting SQL Server do what it does best using SET theory for determining
> updates and inserts, but also doing it in small enough chunks that other
> processing can continue with only slight interruption.
> Just my .02
>
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>
>

Opinios: SQL DB Dev MCP Exam 70-229

I'm terrified, and could use some opinions from the user community...
I'm about to take my first ever Microsoft MCP exam on SQL Server 2000
Development (70-229). To prepare, I've been reading the SQL Server 2000
Design Exam Study Guide from Sybex Books.
One of the problems I have is with ambiguously-worded questions. One example
is this:
You have data stored in SQL Server and Oracle. Occasionally, you need to
access data from both sources as a single result set. How should you do this
?
A. Add the Oracle server as a linked server.
B. Use the DTS Import Wizard to import the data from Oracle into SQL Server.
C. Use the OPENROWSET function to access the Oracle data.
D. Export the data from Oracle to a text file, and import it into SQL Server
using BULK INSERT.
Now, although it seems all 4 technically would work, the obvious first step
is to narrow it down to A and C (B and D are too cumbersome).
Linked servers should be used if the data is accessed FREQUENTLY. OPENROWSET
should be used if the data is accessed INFREQUENTLY. I have a full
understanding of that concept.
How often is "occasionally," as it is worded in the question?
In my world,
Frequently = 90% of the time
Infrequntly = 10% of the time
Occasionally = 30 - 50% of the time.
The only other guideline I have is elsewhere in the book, where it states in
a big NOTE area:
"If access to a data source is needed more than a handful of times, the
source should be registered with SQL Server" a.k.a. linked table.
Is "occasional" more than a "handful?"
I thought so. I said Linked Server. The Sybex author thinks "occasional" =
"infrquent," and that the correct answer is OPENROWSET.
I got the question wrong. Or so says Sybex.
Here's my question for opinions: For those who have taken this MCP exam, do
the Microsoft authors word the questions on the MCP exam as ambiguously as
the authors from Sybex?
It seems if the question has a black-and-white right-and-wrong answer, then
the question should have a more black-and-white wording, and not use words
like "occasional," that different people will interpret differently.
Ultimately, I'm afraid I will get questions wrong, not because of lack of
understanding of the subject matter, but from ambiguous wording of the
questions. Are the Microsoft questions this loosely worded?
Thanks!If you are prepared, most of the questions on the exam will appear to you to
have only one correct answer. The sample question you provided is poorly
written and misleading (In addition to being an MCDBA, I tought at colleges
for about 5 years). I have used Sybex books for other certifications, and I
think that it is a pattern with their products. Although the main text may b
e
well-written by a reputable author, very often the question banks are writte
n
by someone else. Even so, the question may have served its purpose by gettin
g
you to research and think about the answer, even though your answer wasn't
"right."
That being said, you probably will encounter at least one question during
the exam that seems to have either no or multiple correct answers. It might
be a "throw away" question placed on your exam to test the *question* for
usability in later exams.
In addition to your technical studying routine, I would also recommend
looking at some resources for dealing with test anxiety; you're opening of
"I'm terrified" give you away :-) . Good luck!
"Joel" wrote:

> I'm terrified, and could use some opinions from the user community...
> I'm about to take my first ever Microsoft MCP exam on SQL Server 2000
> Development (70-229). To prepare, I've been reading the SQL Server 2000
> Design Exam Study Guide from Sybex Books.
> One of the problems I have is with ambiguously-worded questions. One examp
le
> is this:
> You have data stored in SQL Server and Oracle. Occasionally, you need to
> access data from both sources as a single result set. How should you do th
is?
> A. Add the Oracle server as a linked server.
> B. Use the DTS Import Wizard to import the data from Oracle into SQL Serve
r.
> C. Use the OPENROWSET function to access the Oracle data.
> D. Export the data from Oracle to a text file, and import it into SQL Serv
er
> using BULK INSERT.
> Now, although it seems all 4 technically would work, the obvious first ste
p
> is to narrow it down to A and C (B and D are too cumbersome).
> Linked servers should be used if the data is accessed FREQUENTLY. OPENROWS
ET
> should be used if the data is accessed INFREQUENTLY. I have a full
> understanding of that concept.
> How often is "occasionally," as it is worded in the question?
> In my world,
> Frequently = 90% of the time
> Infrequntly = 10% of the time
> Occasionally = 30 - 50% of the time.
> The only other guideline I have is elsewhere in the book, where it states
in
> a big NOTE area:
> "If access to a data source is needed more than a handful of times, the
> source should be registered with SQL Server" a.k.a. linked table.
> Is "occasional" more than a "handful?"
> I thought so. I said Linked Server. The Sybex author thinks "occasional" =
> "infrquent," and that the correct answer is OPENROWSET.
> I got the question wrong. Or so says Sybex.
> Here's my question for opinions: For those who have taken this MCP exam, d
o
> the Microsoft authors word the questions on the MCP exam as ambiguously as
> the authors from Sybex?
> It seems if the question has a black-and-white right-and-wrong answer, the
n
> the question should have a more black-and-white wording, and not use words
> like "occasional," that different people will interpret differently.
> Ultimately, I'm afraid I will get questions wrong, not because of lack of
> understanding of the subject matter, but from ambiguous wording of the
> questions. Are the Microsoft questions this loosely worded?
> Thanks!|||Joel,
First off, good luck on the exams. Second, I have written a score of books
for Sybex, (The SQL 2k Admin guide being one of them, Note: I did not write
the Development Guide).
The sample questions in the books are of two varieties. One set is to
ensure that you have specific knowledge about the subject. The second set
of questions will have a similar look and feel to the live questions on the
exam.
As far as ambiguity is concerned, the example you gave below could be
construed as ambiguous unless you have read the chapters carefully. In the
Admin book, we would normally discuss what is "occasional usage" or "a
handful of times" in the same set of paragraphs where we discuss the
OPENROWSET command. It should give you a mental link between those words
(occasional usage, handful of times) and OPENROWSET. Likewise, in the
Linked Server section it should discuss with words like "frequent" and
"often".
In addition to the Sybex books, I would suggest you purchase and go through
some sample exams. MeasureUp and Transcender do a pretty good job of test
prepping you with questions. They tell you why the correct answer is
correct and more importantly why the incorrect answers don't match the
questions. (This information will give you much broader depth of knowledge
about the subject as most answers are TRUE statements, but don't necessarily
apply to the question given.)
Some information about the questions themselves. In general, you need to
read the question carefully and pick the answer which correctly solves the
QUESTION as given. You will find that in most cases, the answers provided
will all be TRUE statements about SQL Server, but only the correct answer
will apply to the question given.
In some instances (as you have shown below), all the solutions given could
successfully answer the question, but from that you need to cull the BEST
solution given the parameters of the question itself. In those situations,
make sure that you factor in what Microsoft thinks is the BEST solution.
As an example, in the real world, a Primary Key should uniquely identify a
single row in a table. A natural key could do that (Like a UPC code for a
product). The Microsoft answer however would be that you should always use
a surrogate key, even if a valid natural key is available. In the real
world you would need to determines the pros and cons of using that UPC code
versus a surrogate.
HTH
Best of luck on the exams!
Rick Sawtell
MCT, MCSD, MCDBA
"Joel" <Joel@.discussions.microsoft.com> wrote in message
news:49E3DB04-9969-4A65-85DB-B82CC92F9BD7@.microsoft.com...
> I'm terrified, and could use some opinions from the user community...
> I'm about to take my first ever Microsoft MCP exam on SQL Server 2000
> Development (70-229). To prepare, I've been reading the SQL Server 2000
> Design Exam Study Guide from Sybex Books.
> One of the problems I have is with ambiguously-worded questions. One
> example
> is this:
> You have data stored in SQL Server and Oracle. Occasionally, you need to
> access data from both sources as a single result set. How should you do
> this?
> A. Add the Oracle server as a linked server.
> B. Use the DTS Import Wizard to import the data from Oracle into SQL
> Server.
> C. Use the OPENROWSET function to access the Oracle data.
> D. Export the data from Oracle to a text file, and import it into SQL
> Server
> using BULK INSERT.
> Now, although it seems all 4 technically would work, the obvious first
> step
> is to narrow it down to A and C (B and D are too cumbersome).
> Linked servers should be used if the data is accessed FREQUENTLY.
> OPENROWSET
> should be used if the data is accessed INFREQUENTLY. I have a full
> understanding of that concept.
> How often is "occasionally," as it is worded in the question?
> In my world,
> Frequently = 90% of the time
> Infrequntly = 10% of the time
> Occasionally = 30 - 50% of the time.
> The only other guideline I have is elsewhere in the book, where it states
> in
> a big NOTE area:
> "If access to a data source is needed more than a handful of times, the
> source should be registered with SQL Server" a.k.a. linked table.
> Is "occasional" more than a "handful?"
> I thought so. I said Linked Server. The Sybex author thinks "occasional" =
> "infrquent," and that the correct answer is OPENROWSET.
> I got the question wrong. Or so says Sybex.
> Here's my question for opinions: For those who have taken this MCP exam,
> do
> the Microsoft authors word the questions on the MCP exam as ambiguously as
> the authors from Sybex?
> It seems if the question has a black-and-white right-and-wrong answer,
> then
> the question should have a more black-and-white wording, and not use words
> like "occasional," that different people will interpret differently.
> Ultimately, I'm afraid I will get questions wrong, not because of lack of
> understanding of the subject matter, but from ambiguous wording of the
> questions. Are the Microsoft questions this loosely worded?
> Thanks!

Opinions wanted

Hello,
I have a quick question.
I am considering training for SQL200. Possibly as a career change. But, before I take that step, I wanted to ask all you guru's what I might expect from the job market?
Or instead of SQL2000 should I consider a different database (Oracle, etc)?
I currently program C++.

I know I should probably have posted this in a different section, but I felt that this will get more of the traffic I am after.

Thanks for any input. Also, feel free to email me if that is a better option.

Thanks,
David
dbarnes5@.kscable.comis money your priority? what exactly are you looking for?

I worked with sql as a developer and loved it so much i starting doing database administration, but money was not the motive. it was the enjoyment.

if money is your motive :( but oracle makes more. if enjoyment is your motive, you'll have to decide between the two.

the job market is "decent" for ppl who have 3 years experience and pretty darn good for 6 years+

If you have 0 years experience adminstration but more years of SQL Development, youmight have better luck becoming a SQL Developer first then a DBA.

Opinions Please

Hi, I have probably exhusted the topic of shapes etc... but I am still having a hard time determining the best solution for my problem:

I have several products, each with several specific properties:

Double Tee
-------------
Width | Height |Flange | Leg | Count

Column
--------
Width | Height

Round Column
------
Radius

Now originally I wanted to create a scalable table structure, so with the help of several people on this site (and SQL Team) I have developed the following :
tbShape
------
ShapeID | Shape | XSectionFormula
--------------
1 | Rect | Length X Width

tbShapeAttributes
------------
fkShapeID | AttributeID | Attribute
------------
1 | 1 | Length
1 | 2 | Width

tbProduct
------------
ProductID | fkShapeID | Product
------------
1 | 1 | Column

tbProductAttributeValues
--------------
fkProductID | fkAttributeID | Value
--------------
1 | 1 | 10
1 | 1 | 10
[/code]

From the above table structure I was able to select a product
and by obtaining the formula from the tbShape table, using a
cursor, replacing the Attribute names in the formula with the
attribute values from the tbProductAttributeValues table, using
dynamic SQL, I am able to determine the cross section of any
selected product.

The Problem now is, what if I need to apply different functions to
the data for any given product. This proves to be very difficult because
the attributes for the product are not necessarily consistent.

For Example, lets say the above was a slab 10 feet by 1 foot giving a cross section of 10 square feet. Because it is simple to get the cross sectional area, I can easily figure out the cubic feet of concrete used by multiplying the cross section by a length. But lets say the user want to get the cost / square foot? How is the application sure what attribute is the width of the product?

I guess what I am getting at is why the structure below is not any better then the one above?

tbTemplateCategories
------------
CategoryID | Category

tbTemplates
------------
TemplateID | fkCategoryID | Template |
-------------

tbDoubleTeeTemplates
-------------
fkTemplateID | Width | Height | Flange | Avg. Leg Width | Leg Count

tbWallTemplates
-------------
fkTemplateID | Width | Height

Now there would be a 1 - 1 relationship between the tbTemplates and tbDoubleTeeTemplates ON TemplateID - fkTemplateID. To add a new product, simple add the category, the new table, and then alter the Stored Procs which would use if() if else() statements based on the category to go to the appropriate template table.

Also, now I can write any customized functions for any product without the worry of user mispelling an attribute between the formula and attributes, etc...

Any opinions, thoughts on this would be appreciated!

Mike BAfter a little research, I found that this is refered to as sub-typing. This seems to be a very logical approach to the scenerio I have outlined. Even for shapes, this should be the way to go rather then trying to create a shapes - shape properties 1:M relationship. It seems to be more sound, manageable, and mantainable. So are those three attributes worth the tradeoff of flexibility? I am not convinced the flexibility is even lost seeing how easy it is to add a category then a sub_entity table for the attributes?

Mike B|||Mike-

We had a similar situation in our project and I tokk the exact same approach as yours. I have a tblProduct, tblAttribute, tblProductAttribute, tblProductAttributeValue. The challange was when the UI team asked me to return a product and all the attribute values in the same row. (The attributename should be the column name !!). The only way we could do it was through dynamic SQL. There was a lot of looping that goes on in the SP. I am not terribly pleased with this solution. While it gave us the flexibility of adding new products without changing the schema, there is a lot of performance hit we need to take that comes with it.

That's just me.

- cbarus|||Originally posted by sbaru
Mike-

We had a similar situation in our project and I tokk the exact same approach as yours. I have a tblProduct, tblAttribute, tblProductAttribute, tblProductAttributeValue. The challange was when the UI team asked me to return a product and all the attribute values in the same row. (The attributename should be the column name !!). The only way we could do it was through dynamic SQL. There was a lot of looping that goes on in the SP. I am not terribly pleased with this solution. While it gave us the flexibility of adding new products without changing the schema, there is a lot of performance hit we need to take that comes with it.

That's just me.

- cbarus
That is what I am afraid of. I am wondering if the flexibility is worth it if we were to only add one product / ohhh, who knows. I have been with this company for 10 years and I have never seen a new product.

Mike B|||Originally posted by sbaru
Mike-

We had a similar situation in our project and I tokk the exact same approach as yours. I have a tblProduct, tblAttribute, tblProductAttribute, tblProductAttributeValue. The challange was when the UI team asked me to return a product and all the attribute values in the same row. (The attributename should be the column name !!). The only way we could do it was through dynamic SQL. There was a lot of looping that goes on in the SP. I am not terribly pleased with this solution. While it gave us the flexibility of adding new products without changing the schema, there is a lot of performance hit we need to take that comes with it.

That's just me.

- cbarus

Are there any calucluations with the the attributes of your products? How are these handled?

Mike B

Opinions on SQL Server hardware

Planned server:
Windows Server 2003
4 GB RAM
SQL 2000 Standard (ERP app does not yet support SQL 2005)
RAID1 for OS
RAID 10 for SQL data
RAID1 for SQL logs
RAID1 for temp db
Dual, teamed NICs

I would try to get 15K SCSI drives. Any thoughts on SATA instead of SCSI?

Could I expect much of an impovement by using SQL 2000 Enterprise since it
can use more RAM? I would rather wait for SQL 2005 to be supported.

Does anyone have a Dell or HP server configured in an email-able cart that
they would care to share?

Thank you.Artie (artie2269@.yahoo.com) writes:

Quote:

Originally Posted by

I was wondering if I could get some experienced opinions on SQL hardware
to run an ERP app on SQL 2000. The app does not yet support SQL 2005.
The ERP app has 25 users and likely won't exceed 30 users for several
years. All traffic is on the LAN. The ERP clients basically submit SQL
requests for reads and writes. The app makes heavy use of temp tables,
temp views but not many stored procedures. The current size of the db
is 6GB and will likely double in 4 years.
>
Planned server:
Windows Server 2003
4 GB RAM
SQL 2000 Standard (ERP app does not yet support SQL 2005)
RAID1 for OS
RAID 10 for SQL data
RAID1 for SQL logs
RAID1 for temp db
Dual, teamed NICs
>
I would try to get 15K SCSI drives. Any thoughts on SATA instead of SCSI?

Hardware recommendations is not my best game, and it's always a gamble,
because there are so many "It depends". But from what you say, this
appears to be a very able server for your database.

Quote:

Originally Posted by

Could I expect much of an impovement by using SQL 2000 Enterprise since it
can use more RAM? I would rather wait for SQL 2005 to be supported.

Given the price tag of Enterprise, I find it difficult to recommend
Enterprise when your database is that modest.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||i've dealt with extreme traffic with dual xeon dual core with 6GB ram,
win 2003 ent, sql ent. we were using standard edition with sql 2003
standard. the db size then was about 4GB. traffic was high (for me) at
few hundred per sec.
we had to change the db design to utilize select-inserts rather than
traditional updates. and change all non critical selects with (NOLOCK)
locking. with (NOLOCK) saved my job.
but if u ask me about the improvement using enterprise version over
standard version, personally from my limited experience, i'd say
unnoticable.
now, using RAMDISK boost performance almost two-fold.

On Oct 9, 12:23 am, "Artie" <artie2...@.yahoo.comwrote:

Quote:

Originally Posted by

Hi all,
I was wondering if I could get some experienced opinions on SQL hardware to
run an ERP app on SQL 2000. The app does not yet support SQL 2005. The ERP
app has 25 users and likely won't exceed 30 users for several years. All
traffic is on the LAN. The ERP clients basically submit SQL requests for
reads and writes. The app makes heavy use of temp tables, temp views but
not many stored procedures. The current size of the db is 6GB and will
likely double in 4 years.
>
Planned server:
Windows Server 2003
4 GB RAM
SQL 2000 Standard (ERP app does not yet support SQL 2005)
RAID1 for OS
RAID 10 for SQL data
RAID1 for SQL logs
RAID1 for temp db
Dual, teamed NICs
>
I would try to get 15K SCSI drives. Any thoughts on SATA instead of SCSI?
>
Could I expect much of an impovement by using SQL 2000 Enterprise since it
can use more RAM? I would rather wait for SQL 2005 to be supported.
>
Does anyone have a Dell or HP server configured in an email-able cart that
they would care to share?
>
Thank you.

|||On Mon, 8 Oct 2007 09:23:58 -0700, "Artie" <artie2269@.yahoo.com>
wrote:

I don't consider SATA suitable for servers. Too many crashes of the
RAID array. Pay the extra money and get a proven technology.

-Tom.

<clip>

Quote:

Originally Posted by

>
>I would try to get 15K SCSI drives. Any thoughts on SATA instead of SCSI?
>
>Could I expect much of an impovement by using SQL 2000 Enterprise since it
>can use more RAM? I would rather wait for SQL 2005 to be supported.
>
>Does anyone have a Dell or HP server configured in an email-able cart that
>they would care to share?
>
>Thank you.
>
>

Opinions on Organizing - Solutions and Projects

How are you organizing your solutions and projects? Are you creating a new
solution for every 'group' of reports? I am starting to wonder if I am
getting too granular and will have problems later on locating the reports.
All my reports have the same shared data source.
Right now, I am creating solutions for general headings - for example:
Productivity - obviously has all the productivity reports
Grants - I had seperated these out by individual grants (each grant has it's
own solution and own projects). Would it be easier to manage if all the
grants were in the same solution with different projects?We are organising our reports by having multiple projects under the one
solution.|||I'm developing custom reports for various customers, based on OLAP cubes and
SQL Server 2000 databases. These usually look similar, but are not
identical. This means I can't have the same data source for all reports.
I usually have one solution for each customer. Then I usually add different
projects under each solution, depending on the complexity of the order. I
usually start out with 2 projects: Dev and Final. Dev contains all reports
with static queries. Final contains the reports with dynamic queries based
on parameters. If the customer also orders some of our standard reports,
they go in 2 new projects, Standard Dev and Standard Final, in the same
solution.
Kaisa M. Lindahl Lervik
"WonderingFool" <WonderingFool@.discussions.microsoft.com> wrote in message
news:3E9D563B-78C7-431F-BAC5-47A971C6FFE1@.microsoft.com...
> How are you organizing your solutions and projects? Are you creating a
> new
> solution for every 'group' of reports? I am starting to wonder if I am
> getting too granular and will have problems later on locating the reports.
> All my reports have the same shared data source.
> Right now, I am creating solutions for general headings - for example:
> Productivity - obviously has all the productivity reports
> Grants - I had seperated these out by individual grants (each grant has
> it's
> own solution and own projects). Would it be easier to manage if all the
> grants were in the same solution with different projects?|||I use solution with multiple projects in Visual Studio 2005. Also I organize
projects using folders, so I am very flexible in the number levels of
projects categories.

Opinions on Option (Keepfixed Plan)

I've got this situation where a certain large stored proc (that's used
all day long) just compiles way too often, to the point where it hurts
the performance. I've tried all the tricks I could find to reduce the
number of compilations. So my last option is to use Option (Keepfixed
Plan) hint.
Are there any downsides to using Option (Keepfixed Plan)?
Regards
Hi Frank
Have you read these article to determine the cause of the recompilations and
address the actual reasons?
Troubleshooting stored procedure recompilation
http://support.microsoft.com/kb/243586
How to identify the cause of recompilation in an SP:Recompile event
http://support.microsoft.com/kb/308737
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"Frank Rizzo" <none@.none.com> wrote in message
news:uuunQQy5GHA.4064@.TK2MSFTNGP03.phx.gbl...
> I've got this situation where a certain large stored proc (that's used all
> day long) just compiles way too often, to the point where it hurts the
> performance. I've tried all the tricks I could find to reduce the number
> of compilations. So my last option is to use Option (Keepfixed Plan)
> hint.
> Are there any downsides to using Option (Keepfixed Plan)?
> Regards
|||Kalen Delaney wrote:
> Hi Frank
> Have you read these article to determine the cause of the recompilations and
> address the actual reasons?
> Troubleshooting stored procedure recompilation
> http://support.microsoft.com/kb/243586
> How to identify the cause of recompilation in an SP:Recompile event
> http://support.microsoft.com/kb/308737
Yep, I did all these. I decreased SP:Recompile events in Profiler
substantially, however, they were still happening quite a bit.
Inserting Option (Keepfixed Plan) got rid of the SP:Recompile events and
(anecdotally) increased the performance of the stored proc. In Perfmon,
however, I still get a large number for the SQL Statistic/SQL
Compilations. It must mean something else than what is reflected by the
SP:Recompile event in Profiler.
|||Frank Rizzo wrote:
> Kalen Delaney wrote:
> Yep, I did all these. I decreased SP:Recompile events in Profiler
> substantially, however, they were still happening quite a bit.
> Inserting Option (Keepfixed Plan) got rid of the SP:Recompile events and
> (anecdotally) increased the performance of the stored proc. In Perfmon,
> however, I still get a large number for the SQL Statistic/SQL
> Compilations. It must mean something else than what is reflected by the
> SP:Recompile event in Profiler.
If the recompilations are caused by a large amount of
inserts/updates/deletes, then you could experiment with turning off
auto-update statistics and run a schedule to manually update the
statistics at a time that is convenient for you.
Gert-Jan
|||Gert-Jan Strik wrote:
> Frank Rizzo wrote:
> If the recompilations are caused by a large amount of
> inserts/updates/deletes, then you could experiment with turning off
> auto-update statistics and run a schedule to manually update the
> statistics at a time that is convenient for you.
I turned off the auto-update stats from the get go, but the problem is
still happening.

> Gert-Jan

Opinions on Option (Keepfixed Plan)

I've got this situation where a certain large stored proc (that's used
all day long) just compiles way too often, to the point where it hurts
the performance. I've tried all the tricks I could find to reduce the
number of compilations. So my last option is to use Option (Keepfixed
Plan) hint.
Are there any downsides to using Option (Keepfixed Plan)?
RegardsHi Frank
Have you read these article to determine the cause of the recompilations and
address the actual reasons?
Troubleshooting stored procedure recompilation
http://support.microsoft.com/kb/243586
How to identify the cause of recompilation in an SP:Recompile event
http://support.microsoft.com/kb/308737
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"Frank Rizzo" <none@.none.com> wrote in message
news:uuunQQy5GHA.4064@.TK2MSFTNGP03.phx.gbl...
> I've got this situation where a certain large stored proc (that's used all
> day long) just compiles way too often, to the point where it hurts the
> performance. I've tried all the tricks I could find to reduce the number
> of compilations. So my last option is to use Option (Keepfixed Plan)
> hint.
> Are there any downsides to using Option (Keepfixed Plan)?
> Regards|||Kalen Delaney wrote:
> Hi Frank
> Have you read these article to determine the cause of the recompilations and
> address the actual reasons?
> Troubleshooting stored procedure recompilation
> http://support.microsoft.com/kb/243586
> How to identify the cause of recompilation in an SP:Recompile event
> http://support.microsoft.com/kb/308737
Yep, I did all these. I decreased SP:Recompile events in Profiler
substantially, however, they were still happening quite a bit.
Inserting Option (Keepfixed Plan) got rid of the SP:Recompile events and
(anecdotally) increased the performance of the stored proc. In Perfmon,
however, I still get a large number for the SQL Statistic/SQL
Compilations. It must mean something else than what is reflected by the
SP:Recompile event in Profiler.|||Frank Rizzo wrote:
> Kalen Delaney wrote:
> > Hi Frank
> >
> > Have you read these article to determine the cause of the recompilations and
> > address the actual reasons?
> >
> > Troubleshooting stored procedure recompilation
> > http://support.microsoft.com/kb/243586
> >
> > How to identify the cause of recompilation in an SP:Recompile event
> > http://support.microsoft.com/kb/308737
> Yep, I did all these. I decreased SP:Recompile events in Profiler
> substantially, however, they were still happening quite a bit.
> Inserting Option (Keepfixed Plan) got rid of the SP:Recompile events and
> (anecdotally) increased the performance of the stored proc. In Perfmon,
> however, I still get a large number for the SQL Statistic/SQL
> Compilations. It must mean something else than what is reflected by the
> SP:Recompile event in Profiler.
If the recompilations are caused by a large amount of
inserts/updates/deletes, then you could experiment with turning off
auto-update statistics and run a schedule to manually update the
statistics at a time that is convenient for you.
Gert-Jan|||Gert-Jan Strik wrote:
> Frank Rizzo wrote:
>> Kalen Delaney wrote:
>> Hi Frank
>> Have you read these article to determine the cause of the recompilations and
>> address the actual reasons?
>> Troubleshooting stored procedure recompilation
>> http://support.microsoft.com/kb/243586
>> How to identify the cause of recompilation in an SP:Recompile event
>> http://support.microsoft.com/kb/308737
>> Yep, I did all these. I decreased SP:Recompile events in Profiler
>> substantially, however, they were still happening quite a bit.
>> Inserting Option (Keepfixed Plan) got rid of the SP:Recompile events and
>> (anecdotally) increased the performance of the stored proc. In Perfmon,
>> however, I still get a large number for the SQL Statistic/SQL
>> Compilations. It must mean something else than what is reflected by the
>> SP:Recompile event in Profiler.
> If the recompilations are caused by a large amount of
> inserts/updates/deletes, then you could experiment with turning off
> auto-update statistics and run a schedule to manually update the
> statistics at a time that is convenient for you.
I turned off the auto-update stats from the get go, but the problem is
still happening.
> Gert-Jan

Opinions on Option (Keepfixed Plan)

I've got this situation where a certain large stored proc (that's used
all day long) just compiles way too often, to the point where it hurts
the performance. I've tried all the tricks I could find to reduce the
number of compilations. So my last option is to use Option (Keepfixed
Plan) hint.
Are there any downsides to using Option (Keepfixed Plan)?
RegardsHi Frank
Have you read these article to determine the cause of the recompilations and
address the actual reasons?
Troubleshooting stored procedure recompilation
http://support.microsoft.com/kb/243586
How to identify the cause of recompilation in an SP:Recompile event
http://support.microsoft.com/kb/308737
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"Frank Rizzo" <none@.none.com> wrote in message
news:uuunQQy5GHA.4064@.TK2MSFTNGP03.phx.gbl...
> I've got this situation where a certain large stored proc (that's used all
> day long) just compiles way too often, to the point where it hurts the
> performance. I've tried all the tricks I could find to reduce the number
> of compilations. So my last option is to use Option (Keepfixed Plan)
> hint.
> Are there any downsides to using Option (Keepfixed Plan)?
> Regards|||Kalen Delaney wrote:
> Hi Frank
> Have you read these article to determine the cause of the recompilations a
nd
> address the actual reasons?
> Troubleshooting stored procedure recompilation
> http://support.microsoft.com/kb/243586
> How to identify the cause of recompilation in an SP:Recompile event
> http://support.microsoft.com/kb/308737
Yep, I did all these. I decreased SP:Recompile events in Profiler
substantially, however, they were still happening quite a bit.
Inserting Option (Keepfixed Plan) got rid of the SP:Recompile events and
(anecdotally) increased the performance of the stored proc. In Perfmon,
however, I still get a large number for the SQL Statistic/SQL
Compilations. It must mean something else than what is reflected by the
SP:Recompile event in Profiler.|||Frank Rizzo wrote:
> Kalen Delaney wrote:
> Yep, I did all these. I decreased SP:Recompile events in Profiler
> substantially, however, they were still happening quite a bit.
> Inserting Option (Keepfixed Plan) got rid of the SP:Recompile events and
> (anecdotally) increased the performance of the stored proc. In Perfmon,
> however, I still get a large number for the SQL Statistic/SQL
> Compilations. It must mean something else than what is reflected by the
> SP:Recompile event in Profiler.
If the recompilations are caused by a large amount of
inserts/updates/deletes, then you could experiment with turning off
auto-update statistics and run a schedule to manually update the
statistics at a time that is convenient for you.
Gert-Jan|||Gert-Jan Strik wrote:
> Frank Rizzo wrote:
> If the recompilations are caused by a large amount of
> inserts/updates/deletes, then you could experiment with turning off
> auto-update statistics and run a schedule to manually update the
> statistics at a time that is convenient for you.
I turned off the auto-update stats from the get go, but the problem is
still happening.

> Gert-Jan

Opinions on Dell's rebranded EMC CX line and Fibre Channel gear?

Hi all -
I'm curious if any of you are running Dell's rebranded EMC CX line of
storage enclosures and if so, what your experiences with them have been.
Also, any experiences with their Fibre Channel offerings would be greatly
appreciated. Thanks.
-MB
I was one of their earliest customers shortly after they announced the deal.
I started with one CX-600 and ended up with two CX-600s and a CX-700. There
were some early support issues, especially with escalation to EMC, but those
got ironed out long ago. The biggest difference is in deployment. EMC
builds the system in their factory then disasembles it for shipping. Dell
does a "dock merge". That is, the first time the components see each other
is at your location. They also do a minimum of engineering design work on
the deployment. EMC or Unisys sells the same gear for higher prices, but
they do include a lot of "soft smarts" with the systems. I would purchase
and recommend a Dell CX system, but then again, I have a fair amount of
experience and don't need the extra engineering design support. If you are
just starting out with a SAN, you may want to go with a higher priced
vendor that holds your hand a lot more. EIther way, the hardware is good
stuff.
Geoff N. Hiten
"mb" <mb@.discussions.microsoft.com> wrote in message
news:AE016978-B818-4611-A7EF-47B27CABF223@.microsoft.com...
> Hi all -
> I'm curious if any of you are running Dell's rebranded EMC CX line of
> storage enclosures and if so, what your experiences with them have been.
> Also, any experiences with their Fibre Channel offerings would be
> greatly
> appreciated. Thanks.
> -MB
>

Opinions needed on AutoMate to replace SQLAgent

We have been told by the director over the DBAs that we may be standardizing ALL scheduled jobs and tasks (including SQL jobs) onto 1 tool called AutoMate (by NetworkAutomation), although I suspect the decision has already been made. I've argued that a standard for batch jobs is good but SQL has a job scheduler designed for SQL and integrated with SQL that works extremely well, but don't think I'm getting through.
Has anyone used AutoMate as a replacement for SQLAgent? I am open to hearing both pros and cons please. Thank you.

Signed, Frustrated DBAI don't see anything on their site that even mentions sql server

What about sercurity?

Looks like you'd have to write bat file with osql and then schedule them

They're not thinking of disabling the agent are they?

That would be bad|||I guess it depends on how much functionality you are willing to give up, how much developer time you are willing to invest on an ongoing basis to support giving up that functionality, and how much the folks at AutoMate are willing to pay your managment.

It is their call on what tools to use. If they are willing to spend enough, they can have whatever they want. You might suggest hiring a 24 by 265 operations staff... That can be more powerful and flexible than any scheduling system, if you can afford it.

-PatP|||I'm a MSFT bigot, but have to admit their scheduling tools are in the minor leagues. I have zero experience with AutoMate, however I have worked in what was at the time the world's largest client server environment and we used DEC's (remember them?) high-end scheduler to manage our jobs.

One thing that high-end scheduler's have that SQL Agent lacks is the ease with which job dependencies can be created and monitored. Frankly, SQL Agent was an after-thought and until Microsoft gets serious about it, will remain nothing but an excellent DTS task scheduler.

It seems you can combine AutoMate and SQL Agent and have a much improved environment.

And, PatP, what about the other 100 days ;) With or without a scheduling system, you'll want operations staff available 24x7x365 for any signifcant system.|||I don't see anything on their site that even mentions sql server
<snip>
Looks like you'd have to write bat file with osql and then schedule them

This is essentially what we do, we just use both SQL Agent to schedule SQL Server jobs, and where we need to also run non-SQL Server jobs, we either schedule them from within the agent using a job of type "operating system command" that references (typically) a BAT file on the server somewhere, or go the other way 'round (BAT to SQL Server) as Brett mentions.

I'm not sure it really matters what TOOL you use to do the scheduling, but why buy a new tool when Uncle Bill has provided the basics to get the same stuff done? Either way, you're going to have a mix, since the tool can't get into SQL Server directly, and SQL Server can't get into the tool directly.|||And, PatP, what about the other 100 days ;) With or without a scheduling system, you'll want operations staff available 24x7x365 for any signifcant system.Ummm, I was thinking weekends... Yeah, that's the ticket!

Jeeze Louise! A guy makes a typo... ;)

-PatP|||MaxA,
I've had no complaints with job dependancy by using the Advanced tab of each step defined -OR- in the one case where that wasn't good enough I did a query against sysjobshistory prior to continuing several step later. It was a work around, but it did work.

OSCI|||I don't dispute that you can accomplish what you need with SQL Agent, however I do dispute whether or not the cost/benefit is there. I value people's time over the cost of a tool like this, thus I usually lean towards a 3rd party solution that would free your valuable time to solve more trying problems.

I also direct DBA's, so my view is a bit different than a DBA's view. However, I would ask the DBA's to make that decision and then support it 100% because I know they're a lot smarter than me. And, they're the ones who would have to deal with any problems.

How would you prefer to spend your time - managing SQL Agent jobs or improving your data architecture? I think your director has the right idea, but the wrong approach. Leading extremely talented people can be very challenging, and we all make mistakes (even PatP made a typo today - sorry PatP, but you are always spot on so I gotta give ya a hard time).|||(even PatP made a typo today - sorry PatP, but you are always spot on so I gotta give ya a hard time).Could I interest you in some wonderful waterfront real estate in Louisiana?

-PatP|||Actually, now that I think about it in more detail, I'd be willing to debate the value of a servicable and well understood standard scheduler versus a wiz-bang proprietary one.

I tend to value people's time more than the cost of a software package too. However, I try to keep my eye on the "big picture"... Every employee with SQL Server experience I've interviewed has a good understanding of SQL Agent. Every consultant I've ever dealt with does too.

Even if another package could save five percent of the job setup time due to the features it provided, I don't think I could ever recoup the time that I'd loose explaining the wiz-bang to everyone that needed to use it... The time we spend scheduling and managing jobs is tiny compared to the time we spend explaining the ins and outs of our systems to folks.

If you had a mostly closed shop, with few newcomers, and a huge number of scheduled jobs, you might be able to justify a scheduler with the power of some of the DEC (and more often DECUS) products. 99% of the jobs I see do just fine with the SQL Agent features, and they really couldn't make use of much more. Your milage may vary, but I'd be surprised if many shops could justify the additional complexity of a third party scheduler!

-PatP|||To me it looks like this tool is much more than just a scheduler; it can also be used for automated testing: are my servers up and running, do my client applications work as they should, or do I send some notification (email) that one of the servers is down or about to.

Would you have a single point of failure?

If this tool is to replace all schedulers (how many are there?), including the one in SQL Server, is it just to do that? I would hope management is clear on this, since I'd be making hours on finding out exactly what I can and cannot do with this tool.|||One thing that high-end scheduler's have that SQL Agent lacks is the ease with which job dependencies can be created and monitored. Frankly, SQL Agent was an after-thought and until Microsoft gets serious about it, will remain nothing but an excellent DTS task scheduler.

Can I have a hit of what you're smoking?

DTS? What the hell is that?|||I appreciate all of the feedback and hope to have more over the next few days. I would like to ask if you haven't voted in the poll to please do so if you find the poll an accurate measure for your opinion.

Thank you again.

OSCI

Opinions Needed

I would like some opinions on how you would deal with the following scenario:

We probably have somewhere from 500 to 1000 reports (written in crystal). We also have about 120 clients; each client has their own database.One of the reasons for so many reports is because a lot of our customers want report A but with this or that extra column added so we end up with a lot of custom versions of one report for a particular client.My question is in converting over to Reporting Services, how would you setup the file structure?

Right now, we are thinking that every client is going to have their own folder which would contain all Reports, Models, and Datasources.What do you guys think?

There is a feature called My Reports that you could use. This allows customers to keep their own versions of the reports in their own folders.

http://msdn2.microsoft.com/en-us/library/aa256334(SQL.80).aspx

Opinions needed

Good luck!
Luis
"Kevin3NF" <KHill@.NopeIDontNeedNoSPAM3NF-inc.com> wrote in message
news:unxbQIJ$DHA.2664@.TK2MSFTNGP09.phx.gbl...
> How many users? How much data? How's your budget? How's your experience
> with SQL Server and/or Access?
> Either can do what you've told us, but you've not told us enough. :-)
> --
> Kevin Hill
> President
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
> "Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
> news:%23mxZQkI$DHA.2040@.TK2MSFTNGP12.phx.gbl...
> fields).
Our
delimited
output
I
>|||I will be the only user to output the reports to send to my carriers
As far as how much data is concerned, it depends on the region we are
delivering to, sometimes 20000 all the way up to 250000
Budget is whatever it takes (Software or training) to get the job done
properly.
My experiance with SQL and Access is just as an admin. (Adding and removing
fields for a CRM application and other small admin tasks, nothing to
complex) but I guess I would consider myself a fairly quick study. I do
have some time on my side since we are getting our existing route lists from
another "routing" company. We are merely positioning ourselves to takeover
in several months.
Let me know if you have any other Qs
Shawn J
"Kevin3NF" <KHill@.NopeIDontNeedNoSPAM3NF-inc.com> wrote in message
news:unxbQIJ$DHA.2664@.TK2MSFTNGP09.phx.gbl...
> How many users? How much data? How's your budget? How's your experience
> with SQL Server and/or Access?
> Either can do what you've told us, but you've not told us enough. :-)
> --
> Kevin Hill
> President
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
> "Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
> news:%23mxZQkI$DHA.2040@.TK2MSFTNGP12.phx.gbl...
> fields).
Our
delimited
output
I
>|||Do you think Access can handle up to 350000 different customer records?
"Nico De Greef" <ndg@.denco.be> wrote in message
news:OsRinnI$DHA.3232@.TK2MSFTNGP10.phx.gbl...
> If it's a multi-user application you should use SQL Server.
> If it's just a single user import and print application, Access probably
> will do.
> --
> Nico De Greef
> Belgium
> Freelance Software Architect
> MCP, MCSD, .NET certified
> "Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
> news:%23mxZQkI$DHA.2040@.TK2MSFTNGP12.phx.gbl...
> fields).
Our
delimited
output
I
>|||I don't think Access is optimized for handling that amount of records.
You are the only user using the tool, it could be a little overkill to buy a
server and a SQL Server license just for your import and print task.
You could also use SQL Desktop Edition, it is also limited on the multi user
side but is closer to SQL Server than Access. You won't need a separate
server for this one.
If you should ever need to upgrade to SQL Server it is easier to start from
SQL Server desktop then from Access.
I never use Access, but only because I have the hardware available to run
SQL Server.
Based on your info I would start with SQL Desktop Edition and a reporting
tool of your choice.
Can Access handle the reporting part of the job ? One answer: test it.
Nico De Greef
Belgium
Freelance Software Architect
MCP, MCSD, .NET certified
"Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
news:OKpluIK$DHA.712@.tk2msftngp13.phx.gbl...
> Do you think Access can handle up to 350000 different customer records?
> "Nico De Greef" <ndg@.denco.be> wrote in message
> news:OsRinnI$DHA.3232@.TK2MSFTNGP10.phx.gbl...
> Our
> delimited
> output
which
> I
are
why
>|||This is just my guess that you will be doing more
development in future, most Access applications end up
being migrated to sql server anyway. So I would recommend
to use sql server from the start.

>--Original Message--
>I will be the only user to output the reports to send to
my carriers
>As far as how much data is concerned, it depends on the
region we are
>delivering to, sometimes 20000 all the way up to 250000
>Budget is whatever it takes (Software or training) to get
the job done
>properly.
>My experiance with SQL and Access is just as an admin.
(Adding and removing
>fields for a CRM application and other small admin tasks,
nothing to
>complex) but I guess I would consider myself a fairly
quick study. I do
>have some time on my side since we are getting our
existing route lists from
>another "routing" company. We are merely positioning
ourselves to takeover
>in several months.
>Let me know if you have any other Qs
>Shawn J
>
>
>"Kevin3NF" <KHill@.NopeIDontNeedNoSPAM3NF-inc.com> wrote
in message
>news:unxbQIJ$DHA.2664@.TK2MSFTNGP09.phx.gbl...
How's your experience
us enough. :-)
have a basic
database (Tables and
create route lists for
clients customers.
>Our
tab or comma
>delimited
into SQL and then
>output
routes.
geographical area which
>I
(Since postal codes are
coverage)
with Crystal, why
features in Access?
>
>.
>

Opinions needed

I am somewhat new to database technologies, I only have a basic
understanding of relational databases.
I need to figure out the best way to set up a database (Tables and fields).
Crystal reports will be used for reporting.
I am in the distribution business and I need to create route lists for
people who will go out and deliver catalogs to our clients customers. Our
client will send me their database of customers via tab or comma delimited
file. What I then need to do is import this file into SQL and then output
some nice looking reports for our carriers delivery routes.
The routes will be based on streets in a logical geographical area which I
hope I will be able to organize by postal code. (Since postal codes are
already organized for optimal delivery time and coverage)
I should add that I'm not even sure I need to use SQL with Crystal, why
wouldn't I use Access and just use the reporting features in Access?
Any help will be appreciated.
Shawn JohnsonIf it's a multi-user application you should use SQL Server.
If it's just a single user import and print application, Access probably
will do.
--
Nico De Greef
Belgium
Freelance Software Architect
MCP, MCSD, .NET certified
"Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
news:%23mxZQkI$DHA.2040@.TK2MSFTNGP12.phx.gbl...
> I am somewhat new to database technologies, I only have a basic
> understanding of relational databases.
> I need to figure out the best way to set up a database (Tables and
fields).
> Crystal reports will be used for reporting.
> I am in the distribution business and I need to create route lists for
> people who will go out and deliver catalogs to our clients customers. Our
> client will send me their database of customers via tab or comma delimited
> file. What I then need to do is import this file into SQL and then output
> some nice looking reports for our carriers delivery routes.
> The routes will be based on streets in a logical geographical area which I
> hope I will be able to organize by postal code. (Since postal codes are
> already organized for optimal delivery time and coverage)
> I should add that I'm not even sure I need to use SQL with Crystal, why
> wouldn't I use Access and just use the reporting features in Access?
> Any help will be appreciated.
> Shawn Johnson
>|||How many users? How much data? How's your budget? How's your experience
with SQL Server and/or Access?
Either can do what you've told us, but you've not told us enough. :-)
--
Kevin Hill
President
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
news:%23mxZQkI$DHA.2040@.TK2MSFTNGP12.phx.gbl...
> I am somewhat new to database technologies, I only have a basic
> understanding of relational databases.
> I need to figure out the best way to set up a database (Tables and
fields).
> Crystal reports will be used for reporting.
> I am in the distribution business and I need to create route lists for
> people who will go out and deliver catalogs to our clients customers. Our
> client will send me their database of customers via tab or comma delimited
> file. What I then need to do is import this file into SQL and then output
> some nice looking reports for our carriers delivery routes.
> The routes will be based on streets in a logical geographical area which I
> hope I will be able to organize by postal code. (Since postal codes are
> already organized for optimal delivery time and coverage)
> I should add that I'm not even sure I need to use SQL with Crystal, why
> wouldn't I use Access and just use the reporting features in Access?
> Any help will be appreciated.
> Shawn Johnson
>|||I will interject a little bit of my prferences and expertise on
this...Crystal is a much more robust of a reprting tool than Access. If you
are just developing reports so that users can print them out etc...you can
import everything into Access, and use access as the reporting tool and
create a few nifty little buttons and forms to make it all user friendly
etc...However, one great point that was mentioned was if you are going to
have many people connect to this database and do thier own importing and
reporting and manipulation and you plan on developing an application to
interface with this...Then SQL is the way to go, using crystal reports to
interface with the data. Well crystal won't change the data, but it will
dress up the reports real perty like! :)
Good luck!
Luis
"Kevin3NF" <KHill@.NopeIDontNeedNoSPAM3NF-inc.com> wrote in message
news:unxbQIJ$DHA.2664@.TK2MSFTNGP09.phx.gbl...
> How many users? How much data? How's your budget? How's your experience
> with SQL Server and/or Access?
> Either can do what you've told us, but you've not told us enough. :-)
> --
> Kevin Hill
> President
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
> "Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
> news:%23mxZQkI$DHA.2040@.TK2MSFTNGP12.phx.gbl...
> > I am somewhat new to database technologies, I only have a basic
> > understanding of relational databases.
> >
> > I need to figure out the best way to set up a database (Tables and
> fields).
> > Crystal reports will be used for reporting.
> >
> > I am in the distribution business and I need to create route lists for
> > people who will go out and deliver catalogs to our clients customers.
Our
> > client will send me their database of customers via tab or comma
delimited
> > file. What I then need to do is import this file into SQL and then
output
> > some nice looking reports for our carriers delivery routes.
> >
> > The routes will be based on streets in a logical geographical area which
I
> > hope I will be able to organize by postal code. (Since postal codes are
> > already organized for optimal delivery time and coverage)
> >
> > I should add that I'm not even sure I need to use SQL with Crystal, why
> > wouldn't I use Access and just use the reporting features in Access?
> >
> > Any help will be appreciated.
> >
> > Shawn Johnson
> >
> >
>|||I will be the only user to output the reports to send to my carriers
As far as how much data is concerned, it depends on the region we are
delivering to, sometimes 20000 all the way up to 250000
Budget is whatever it takes (Software or training) to get the job done
properly.
My experiance with SQL and Access is just as an admin. (Adding and removing
fields for a CRM application and other small admin tasks, nothing to
complex) but I guess I would consider myself a fairly quick study. I do
have some time on my side since we are getting our existing route lists from
another "routing" company. We are merely positioning ourselves to takeover
in several months.
Let me know if you have any other Qs
Shawn J
"Kevin3NF" <KHill@.NopeIDontNeedNoSPAM3NF-inc.com> wrote in message
news:unxbQIJ$DHA.2664@.TK2MSFTNGP09.phx.gbl...
> How many users? How much data? How's your budget? How's your experience
> with SQL Server and/or Access?
> Either can do what you've told us, but you've not told us enough. :-)
> --
> Kevin Hill
> President
> 3NF Consulting
> www.3nf-inc.com/NewsGroups.htm
> "Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
> news:%23mxZQkI$DHA.2040@.TK2MSFTNGP12.phx.gbl...
> > I am somewhat new to database technologies, I only have a basic
> > understanding of relational databases.
> >
> > I need to figure out the best way to set up a database (Tables and
> fields).
> > Crystal reports will be used for reporting.
> >
> > I am in the distribution business and I need to create route lists for
> > people who will go out and deliver catalogs to our clients customers.
Our
> > client will send me their database of customers via tab or comma
delimited
> > file. What I then need to do is import this file into SQL and then
output
> > some nice looking reports for our carriers delivery routes.
> >
> > The routes will be based on streets in a logical geographical area which
I
> > hope I will be able to organize by postal code. (Since postal codes are
> > already organized for optimal delivery time and coverage)
> >
> > I should add that I'm not even sure I need to use SQL with Crystal, why
> > wouldn't I use Access and just use the reporting features in Access?
> >
> > Any help will be appreciated.
> >
> > Shawn Johnson
> >
> >
>|||Do you think Access can handle up to 350000 different customer records?
"Nico De Greef" <ndg@.denco.be> wrote in message
news:OsRinnI$DHA.3232@.TK2MSFTNGP10.phx.gbl...
> If it's a multi-user application you should use SQL Server.
> If it's just a single user import and print application, Access probably
> will do.
> --
> Nico De Greef
> Belgium
> Freelance Software Architect
> MCP, MCSD, .NET certified
> "Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
> news:%23mxZQkI$DHA.2040@.TK2MSFTNGP12.phx.gbl...
> > I am somewhat new to database technologies, I only have a basic
> > understanding of relational databases.
> >
> > I need to figure out the best way to set up a database (Tables and
> fields).
> > Crystal reports will be used for reporting.
> >
> > I am in the distribution business and I need to create route lists for
> > people who will go out and deliver catalogs to our clients customers.
Our
> > client will send me their database of customers via tab or comma
delimited
> > file. What I then need to do is import this file into SQL and then
output
> > some nice looking reports for our carriers delivery routes.
> >
> > The routes will be based on streets in a logical geographical area which
I
> > hope I will be able to organize by postal code. (Since postal codes are
> > already organized for optimal delivery time and coverage)
> >
> > I should add that I'm not even sure I need to use SQL with Crystal, why
> > wouldn't I use Access and just use the reporting features in Access?
> >
> > Any help will be appreciated.
> >
> > Shawn Johnson
> >
> >
>|||I don't think Access is optimized for handling that amount of records.
You are the only user using the tool, it could be a little overkill to buy a
server and a SQL Server license just for your import and print task.
You could also use SQL Desktop Edition, it is also limited on the multi user
side but is closer to SQL Server than Access. You won't need a separate
server for this one.
If you should ever need to upgrade to SQL Server it is easier to start from
SQL Server desktop then from Access.
I never use Access, but only because I have the hardware available to run
SQL Server.
Based on your info I would start with SQL Desktop Edition and a reporting
tool of your choice.
Can Access handle the reporting part of the job ? One answer: test it.
--
Nico De Greef
Belgium
Freelance Software Architect
MCP, MCSD, .NET certified
"Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
news:OKpluIK$DHA.712@.tk2msftngp13.phx.gbl...
> Do you think Access can handle up to 350000 different customer records?
> "Nico De Greef" <ndg@.denco.be> wrote in message
> news:OsRinnI$DHA.3232@.TK2MSFTNGP10.phx.gbl...
> > If it's a multi-user application you should use SQL Server.
> > If it's just a single user import and print application, Access probably
> > will do.
> >
> > --
> > Nico De Greef
> > Belgium
> > Freelance Software Architect
> > MCP, MCSD, .NET certified
> >
> > "Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
> > news:%23mxZQkI$DHA.2040@.TK2MSFTNGP12.phx.gbl...
> > > I am somewhat new to database technologies, I only have a basic
> > > understanding of relational databases.
> > >
> > > I need to figure out the best way to set up a database (Tables and
> > fields).
> > > Crystal reports will be used for reporting.
> > >
> > > I am in the distribution business and I need to create route lists for
> > > people who will go out and deliver catalogs to our clients customers.
> Our
> > > client will send me their database of customers via tab or comma
> delimited
> > > file. What I then need to do is import this file into SQL and then
> output
> > > some nice looking reports for our carriers delivery routes.
> > >
> > > The routes will be based on streets in a logical geographical area
which
> I
> > > hope I will be able to organize by postal code. (Since postal codes
are
> > > already organized for optimal delivery time and coverage)
> > >
> > > I should add that I'm not even sure I need to use SQL with Crystal,
why
> > > wouldn't I use Access and just use the reporting features in Access?
> > >
> > > Any help will be appreciated.
> > >
> > > Shawn Johnson
> > >
> > >
> >
> >
>|||This is just my guess that you will be doing more
development in future, most Access applications end up
being migrated to sql server anyway. So I would recommend
to use sql server from the start.
>--Original Message--
>I will be the only user to output the reports to send to
my carriers
>As far as how much data is concerned, it depends on the
region we are
>delivering to, sometimes 20000 all the way up to 250000
>Budget is whatever it takes (Software or training) to get
the job done
>properly.
>My experiance with SQL and Access is just as an admin.
(Adding and removing
>fields for a CRM application and other small admin tasks,
nothing to
>complex) but I guess I would consider myself a fairly
quick study. I do
>have some time on my side since we are getting our
existing route lists from
>another "routing" company. We are merely positioning
ourselves to takeover
>in several months.
>Let me know if you have any other Qs
>Shawn J
>
>
>"Kevin3NF" <KHill@.NopeIDontNeedNoSPAM3NF-inc.com> wrote
in message
>news:unxbQIJ$DHA.2664@.TK2MSFTNGP09.phx.gbl...
>> How many users? How much data? How's your budget?
How's your experience
>> with SQL Server and/or Access?
>> Either can do what you've told us, but you've not told
us enough. :-)
>> --
>> Kevin Hill
>> President
>> 3NF Consulting
>> www.3nf-inc.com/NewsGroups.htm
>> "Shawn Johnson" <sejohnson77@.yahoo.com> wrote in message
>> news:%23mxZQkI$DHA.2040@.TK2MSFTNGP12.phx.gbl...
>> > I am somewhat new to database technologies, I only
have a basic
>> > understanding of relational databases.
>> >
>> > I need to figure out the best way to set up a
database (Tables and
>> fields).
>> > Crystal reports will be used for reporting.
>> >
>> > I am in the distribution business and I need to
create route lists for
>> > people who will go out and deliver catalogs to our
clients customers.
>Our
>> > client will send me their database of customers via
tab or comma
>delimited
>> > file. What I then need to do is import this file
into SQL and then
>output
>> > some nice looking reports for our carriers delivery
routes.
>> >
>> > The routes will be based on streets in a logical
geographical area which
>I
>> > hope I will be able to organize by postal code.
(Since postal codes are
>> > already organized for optimal delivery time and
coverage)
>> >
>> > I should add that I'm not even sure I need to use SQL
with Crystal, why
>> > wouldn't I use Access and just use the reporting
features in Access?
>> >
>> > Any help will be appreciated.
>> >
>> > Shawn Johnson
>> >
>> >
>>
>
>.
>

Opinions for best setup

We have a web server which needs instant results from our SQL Server.
We also have a lot of reports that are run at various times of the day
that hit against a few multi-million record tables and it bogs the SQL
server down. This in turn slows the response of the web server.
Can I setup two SQL Servers with replication or clustering or something
and have the web server hit one SQL server and the reports hit the
other server? Would the reports still bog down the web requests in
this setup (if it's possible)?
Other suggestions are welcome.
Thanks,
CYou can do this a number of ways depending on how up to date the reports
need to be. If you can live with data for the reports that is not real time
you can use log shipping or snapshot replication from the main SQL Server to
another server for the reporting. If it needs to be near real time then you
can use transactional replication. You can find more details on each in
BooksOnLine.
Andrew J. Kelly SQL MVP
"The Cornjerker" <addoty@.gmail.com> wrote in message
news:1131376846.542603.182480@.g44g2000cwa.googlegroups.com...
> We have a web server which needs instant results from our SQL Server.
> We also have a lot of reports that are run at various times of the day
> that hit against a few multi-million record tables and it bogs the SQL
> server down. This in turn slows the response of the web server.
>
> Can I setup two SQL Servers with replication or clustering or something
> and have the web server hit one SQL server and the reports hit the
> other server? Would the reports still bog down the web requests in
> this setup (if it's possible)?
>
> Other suggestions are welcome.
>
> Thanks,
> C
>

Opinions about Insertion Technique

Looking for some insight from the professionals about how they handle
row inserts. Specifically single row inserts through a stored
procedure versus bulk inserts.

One argument are people who say all inserts (and updates and deletions
I guess) should go through stored procedures. The reasoning is that
the developers that code the client side have no reason to understand
HOW the data is stored, just that it is. Another problem is an insert
that deals with multiple tables. It would be very easy for the
developer to forget a step. That last point also applies to business
logic. In my case, adding a security to our SecurityMaster can touch 1
to 4 tables depending on the type of security. Also, certain fields
are required while others are set to null for depending on the type.

Because a stored procedure cannot be passed datasets but only scalar
values, when you need to deal with multiple (i.e. bulk) rows you are
stuck using cursors. This post is NOT about the pros and cons of
cursors. There are plenty of those on the boards (some of them
probably started by me and showing my understanding (or more
correctly, lack of) of the way to do things). Stored procedures also
give you the ability to abort and/or log inserts that cannot happen
because of contraints and/or business rule failures.

Another approach is to write code (not accessible from outside the
database) that handles bulk inserts. You would need to write in rules
to "extract" or "exclude" rows that do not match constraints or
business rules otherwise ALL the inserts would fail because of one bad
row. I guess you could put the "potential" rows into a temp table.
Apply your rules to the temp table and delete / move rows that would
fail. Any rows left can that be bulk inserted. (You could also use the
rows that were moved to another temp table for logging why they
failed.)

So that leaves use with two possible ways to get data into the system.
A single row based approach for client apps and a bulk based for
internal use. But that leaves use with another problem. You now have
business logic in TWO separate areas. You have to remember to modify
code or fix bugs in multiple locations.

For those that are still reading my post, my question is...

How do you handle this? What is the approach you take?Jay

What we have are a series of core stored procedures for single row
insert/update/deletes. As you point out, this may do extra
validation/processing etc. (Examples include security checking,
auditing, optimistic locking, business rule validation etc). These are
auto-generated.

In addition, we sometimes do bulk inserts from another table or data
source. To ensure we dont duplicate validation/processing AND to
ensure all data goes through the one filter before being committed, we
simply call the exact same stored procedure multiple times, typically
from within a cursor, but can be done from code in our case C#.
Depending on the application, this may be done as a transaction block.
We typically let the stored proc do the validation of the data and log
any rows that failed to insert.

This works like a charm for us and I have used this approach in a
number of successful projects.

However, this bulk insert approach does not scale very well and if you
do a lot of batch style processing, you really need to be looking at
customised scripts/stored procedures to get the best performance.

JayCallas@.hotmail.com (Jason) wrote in message news:<f01a7c89.0402042129.6f9090f6@.posting.google.com>...
> Looking for some insight from the professionals about how they handle
> row inserts. Specifically single row inserts through a stored
> procedure versus bulk inserts.
> One argument are people who say all inserts (and updates and deletions
> I guess) should go through stored procedures. The reasoning is that
> the developers that code the client side have no reason to understand
> HOW the data is stored, just that it is. Another problem is an insert
> that deals with multiple tables. It would be very easy for the
> developer to forget a step. That last point also applies to business
> logic. In my case, adding a security to our SecurityMaster can touch 1
> to 4 tables depending on the type of security. Also, certain fields
> are required while others are set to null for depending on the type.
> Because a stored procedure cannot be passed datasets but only scalar
> values, when you need to deal with multiple (i.e. bulk) rows you are
> stuck using cursors. This post is NOT about the pros and cons of
> cursors. There are plenty of those on the boards (some of them
> probably started by me and showing my understanding (or more
> correctly, lack of) of the way to do things). Stored procedures also
> give you the ability to abort and/or log inserts that cannot happen
> because of contraints and/or business rule failures.
> Another approach is to write code (not accessible from outside the
> database) that handles bulk inserts. You would need to write in rules
> to "extract" or "exclude" rows that do not match constraints or
> business rules otherwise ALL the inserts would fail because of one bad
> row. I guess you could put the "potential" rows into a temp table.
> Apply your rules to the temp table and delete / move rows that would
> fail. Any rows left can that be bulk inserted. (You could also use the
> rows that were moved to another temp table for logging why they
> failed.)
> So that leaves use with two possible ways to get data into the system.
> A single row based approach for client apps and a bulk based for
> internal use. But that leaves use with another problem. You now have
> business logic in TWO separate areas. You have to remember to modify
> code or fix bugs in multiple locations.
> For those that are still reading my post, my question is...
> How do you handle this? What is the approach you take?|||Jason (JayCallas@.hotmail.com) writes:
> Because a stored procedure cannot be passed datasets but only scalar
> values,

Actually, this is not completely true anymore. With SQL 2000 we got
the rowset provider OPENXML. So you can send in a complex dataset with
data for umpteen tables in one single procedure call.

It is probably still not as effecient as bulk insert, but bulk insert has
its limitations in validation etc. You can use a staging table, but
that comes with a cost of course.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||PromisedOyster@.hotmail.com (Mystery Man) wrote in message news:<87c81238.0402050421.69e0e0a@.posting.google.com>...
> Jay
> What we have are a series of core stored procedures for single row
> insert/update/deletes. As you point out, this may do extra
> validation/processing etc. (Examples include security checking,
> auditing, optimistic locking, business rule validation etc). These are
> auto-generated.

I use a combination - depending on what I want to achieve - if I am
loading a routine 'bulk' load then that runs split into adequate
batches (to minimise impact on transactions and logs) - but if I have
a luser wanting to enter data I like the stored proc approach for all
sorts of reasons.|||My personal experience is that business logic gets more and more
complicated as a project develops. The users wants to change this,
tweak that, etc. And stored procedures are the only sure-fire way I
can accomplish all of the user's requests. I do try to "modularize"
common code. For example, a user wants to view a dataset. The web
page calls the viewdataSP. Inside the viewdataSP, it calls a
userAccessSP. Erland has a pretty good article about how to call
stored procedures from a stored procedure.

Opinions about Idera Database Management Tools

Hello-
Does anyone use Idera Dataase Management Tools? If so, what has your
experiencce been? Would anyone recommend a different databse management
application (esp. for performance tuning, alerts, and easy perusal of DB
statistics.)
Regards-
Eric
I like their tools. DM is quicker, easier to set up then
something like netIQ or MOM. For the money, the tools give
pretty good information and offer ease of use.
They seem to be a decent company to deal with when I've
worked with them before. You can download trial versions
from their site.
-Sue
On Thu, 20 Oct 2005 13:01:02 -0700, Eric Marthinsen
<emarthinsen@.NOSPAMnovemberconsulting.com> wrote:

>Hello-
> Does anyone use Idera Dataase Management Tools? If so, what has your
>experiencce been? Would anyone recommend a different databse management
>application (esp. for performance tuning, alerts, and easy perusal of DB
>statistics.)
>Regards-
> Eric
|||Ditto for me. Their tools are quick and easy. Ohter companies do have more
in-depth stuff, but take longer to set up and typically cost more to
purchase. Their tech support folks make a big effort to help you solve
underlying problems. Also, their product release cycle seems pretty
agressive. They are constantly coming out with new and improved stuff which
makes the maintenance cost well worth it.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:nd10m19snjgbsrra3jjj3plch4f9q3rk7s@.4ax.com...
>I like their tools. DM is quicker, easier to set up then
> something like netIQ or MOM. For the money, the tools give
> pretty good information and offer ease of use.
> They seem to be a decent company to deal with when I've
> worked with them before. You can download trial versions
> from their site.
> -Sue
> On Thu, 20 Oct 2005 13:01:02 -0700, Eric Marthinsen
> <emarthinsen@.NOSPAMnovemberconsulting.com> wrote:
>

opinion question - permanantly deleting records

I have a database "philosophy" question. What are some opinions on
permanant record deletion? This would apply to personnel tables,
inventory tables, or whatever. From an accountant's point of view
records of important information such as this should not be
permanently deleted (e.g. you have 1,500 widgets of a particular SKU
in inventory, wouldn't you want to know every transaction in and out
of inventory from which this figure were derived?). Another case: You
have a total of 1,000 current and ex-employees who have various merit
and/or discipline actions taken based on performance. A record in the
performance files for all employees is generated each time an action
of significance is taken. For legal reasons I would think these
records should reside in the database perpetually. Some users are
concerned that former employees may show up on reports. My proposed
solution is simply to have a field that indicates whether or not an
employee is active or inactive.
Any thoughts on these issues? We don't have a storage problem that is
presenting this, we have rather hefty server space.
Any "White Papers" anyone could recommend would be appreciated.
Thanks!
Slinky
> concerned that former employees may show up on reports. My proposed
> solution is simply to have a field that indicates whether or not an
> employee is active or inactive.
I think you are on the right way..
"slinky" <campbellbrian2001@.yahoo.com> wrote in message
news:389b26e9-8097-4df7-86a9-407a8a8fa3ee@.c33g2000hsd.googlegroups.com...
>I have a database "philosophy" question. What are some opinions on
> permanant record deletion? This would apply to personnel tables,
> inventory tables, or whatever. From an accountant's point of view
> records of important information such as this should not be
> permanently deleted (e.g. you have 1,500 widgets of a particular SKU
> in inventory, wouldn't you want to know every transaction in and out
> of inventory from which this figure were derived?). Another case: You
> have a total of 1,000 current and ex-employees who have various merit
> and/or discipline actions taken based on performance. A record in the
> performance files for all employees is generated each time an action
> of significance is taken. For legal reasons I would think these
> records should reside in the database perpetually. Some users are
> concerned that former employees may show up on reports. My proposed
> solution is simply to have a field that indicates whether or not an
> employee is active or inactive.
> Any thoughts on these issues? We don't have a storage problem that is
> presenting this, we have rather hefty server space.
> Any "White Papers" anyone could recommend would be appreciated.
> Thanks!
|||Thanks! Do you know of any MS or Oracle documentation that addresses
this issue?
On Feb 18, 10:18Xam, "Uri Dimant" <u...@.iscar.co.il> wrote:
> Slinky
>
> I think Xyou are on the right way..
> "slinky" <campbellbrian2...@.yahoo.com> wrote in message
> news:389b26e9-8097-4df7-86a9-407a8a8fa3ee@.c33g2000hsd.googlegroups.com...
>
>
>
> - Show quoted text -
|||I prefer to model this with pairs of dates to indicate a period. For
example, with employees you can have a table that records employee start and
end date for employment. When employee is hired record the start date and
end date is NULL. When employee leaves the company, update the end date to
record that. And having this in a separate table will give you the option to
record multiple events for employee (for example, if rehired). Based on that
you can easily select current active employees, those are employees that
have end date NULL. This will also provide a good trail for auditing if
needed, and it provides much more information that a simple flag.
If you have only a flag for active/inactive, then you can run into some
weird reporting problems, like if somebody asks to run a report of employees
that were active last year. Then if you have an employee that became
inactive in the beginning of this year, you will exclude the employee from
the report because the flag shows inactive, but this is incorrect because
the employee was active last year. Keeping a period of dates will help you
to answer this question correctly.
HTH,
Plamen Ratchev
http://www.SQLStudio.com
|||Does the philosophy include securing the information?
"slinky" wrote:

> I have a database "philosophy" question. What are some opinions on
> permanant record deletion? This would apply to personnel tables,
> inventory tables, or whatever. From an accountant's point of view
> records of important information such as this should not be
> permanently deleted (e.g. you have 1,500 widgets of a particular SKU
> in inventory, wouldn't you want to know every transaction in and out
> of inventory from which this figure were derived?). Another case: You
> have a total of 1,000 current and ex-employees who have various merit
> and/or discipline actions taken based on performance. A record in the
> performance files for all employees is generated each time an action
> of significance is taken. For legal reasons I would think these
> records should reside in the database perpetually. Some users are
> concerned that former employees may show up on reports. My proposed
> solution is simply to have a field that indicates whether or not an
> employee is active or inactive.
> Any thoughts on these issues? We don't have a storage problem that is
> presenting this, we have rather hefty server space.
> Any "White Papers" anyone could recommend would be appreciated.
> Thanks!
>
|||I think it greatly depends on the type of data and the size.
if you're generating a million+ rows of, say, statistical data a day that
you'll only need a 90 day trending on, you obviously want to archive that
stuff and purge it from the database as a matter of course.
Personnel records, on the other hand, are generally required to be kept by
law for certain periods. I've heard 7 years, but a lot of companies keep
that info in perpetuity, which is not a bad idea. The size of a table
related to personnel does not tend to grow out of control.
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:%23SRQZFkcIHA.4332@.TK2MSFTNGP04.phx.gbl...
> Slinky
> I think you are on the right way..
>
>
> "slinky" <campbellbrian2001@.yahoo.com> wrote in message
> news:389b26e9-8097-4df7-86a9-407a8a8fa3ee@.c33g2000hsd.googlegroups.com...
>

Friday, March 9, 2012

Opinons on using Delete then BULK INSERT

Opinios: SQL DB Dev MCP Exam 70-229

Opinions wanted

Opinions Please

Opinions on SQL Server hardware

Opinions on Organizing - Solutions and Projects

Opinions on Option (Keepfixed Plan)

Opinions on Option (Keepfixed Plan)

Opinions on Option (Keepfixed Plan)

Opinions on Dell's rebranded EMC CX line and Fibre Channel gear?

Opinions needed on AutoMate to replace SQLAgent

Opinions Needed

Opinions needed

Opinions needed

Opinions for best setup

Opinions about Insertion Technique

Opinions about Idera Database Management Tools

opinion question - permanantly deleting records

OpenXML Identity Insert

Blog Archive

About Me