Best Project Template & "The View of the event class could not be materialized"

Can someone explain this statement to me. "The View of the event class could not be materialized". I get it when I try to do a build of my Instance.

Also, yesterday I used CopySample to prepare an instance for my project. I'm not sure if this is the right way to go.

Is there a better template to use or process to follow to create a complete project (including Visual Studio Build Scripts, etc...)

Thanks

...Ray

Ray,
"The View of the event class could not be materialized" is a runtime error, not a build-time error. Are you sure you saw this while building your instance?

Here's what the error means:
Before SQL-NS executes the rules in your application (match rules or chronicle rules) it first builds views of the events and subscriptions tables. These views provide the input data for the rules: they contain only the events and subscriptions against which the rule should operate in any given firing. The error means that something when wrong during the process of setting up these views. Usually the rest of the error message provides more detail on the problem. If you could include the complete message, we'd be able to diagnose the problem better. The most common cause of this is a timeout, which can happen if the event batch is huge.

Also, please tell us what version of SQL-NS you're using - is it SQL 2000 (NS2.0) or SQL 2005? If 2005, which build are you using?

Regarding your question about the best template, you can certainly use the ones provided with the samples. However, this does involve starting from a pre-existing application and changing/removing things to make it do what you want. In my book (http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/) I describe how to set up a "minimal" instance and application (with just the elements required to get it to build) and then add the code you want piece by piece. The book's CD-ROM provides all the necessary files and instructions on setting this up.

Hope this helps.
-shyam

Best approach with DTS

Let me see if I can explain this.

I have the need to pull data from multiple tables from a DB2 system via ODBC and update or insert as needed into tables in a SQL200 DB.

Step 1.
The data from the initial parent table will need to be limited to being a set number of days old, which I have in place and working.

Step 2
The next tables data needs to be limited from the data retrieved in step 1 (Id like to use the paprent table retrieved in step 1, that is in SQL now, rather than doing it on the DB2 side.

Step 3
The returned rows here, need to be limited to key values returned from step 2

Additional steps apply, but nearly all will be limited to the results of parent tables from the prior step.

What is the best approach to this? I really want to pull table A to SQL, and limit the next child set from Table A, that was pulled to SQL in the prior step.

I also need to do updates rather than dropping and creating the needed tables each time. Insert if no key exists, etc .etc.

What is the best approach?I think DTS is better in this regard.
You need to workout to re-arrange data based upon the requirement.
Once data is imported you can contro updations from SQL side using normal TSQL.|||I think I'm going to continue to limit the selection on the db2 side based on sub queries. Initially set it up to drop and create the tables each time, and after that's all done, modify to import into temp tables from dts and then use sql to update the existing tables from the temp tables, I think this is the approach I'm going to take.

I'm open to ideas for alternatives

Benefits of 64bit SQL?

Hi,
I'm trying to decide whether our next database server should be 32 or 64
bit. Could someone please explain the benefits of 64bit computing and the
factors I should be looking at in order to determine whether it would be of
value to me?
The only benefit I'm aware of is the fact that memory beyond 4gigs can
be accessed directly -- but surely there must be other benefits as well. I
imagine that the speed at which data is transferred across the bus must be
doubled due to the fatter data path... but given that I'd still be limited
by the I/O speed of the drives, is the performance improvement even
relevant?
Sorry for the newbie questions. I just want to avoid having some slick
talking salesman sell us a 64bit machine if we don't really need it. I want
to know what questions to ask.
Thanks..."The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well.
That's pretty much it. But x64 64 bit does not add any cost to servers.
Intel and AMD's server chips are (basically) all 64 bit chips.
>I imagine that the speed at which data is transferred across the bus must
>be doubled due to the fatter data path... but given that I'd still be
>limited by the I/O speed of the drives, is the performance improvement even
>relevant?
Memory bus speed is a very important performance factor for databse servers.
With several gigabytes of data cached, moving that data in and out of the
CPU is one of the major system bottlenecks. Large on-chip L2 cache helps
here too. However 64 bit systems are not automatically better here. X64
servers use basically the same system boards as 32-bit systems.
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
You definitely want 64bit, since it doesn't really cost you anyting. You
still have to choose between x64 and IA64-based systems. Currently dollar
for dollar x64 is the performance king, but for certian very large workloads
you might need a big IA64 box.
David|||from a performance point of view, for the same hardware and less then 4Gb
there is no difference.
above 4Gb there are small improvements at the DB level. but managing the
memory is more easier.
the performance improvement is at the SSIS & AS levels. with more then 4Gb
these 2 tools takes a big advantage of this memory.
the other advantage is at the OS level.
Standard x64 edition of windows support 32Gb while the 32bits version is
limited to 4Gb.
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>|||http://www.microsoft.com/sql/techinfo/whitepapers/advantages-64bit-environment.mspx
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>|||> However 64 bit systems are not automatically better here. X64 servers use
> basically the same system boards as 32-bit systems.
Hi David,
Could you expand on this a bit? Excuse my ignorance here, but what do
you mean when you say that X64 servers use basically the same system boards
as 32 bit systems? How is that possible? Also, is "X64" just a generic term
that's used to refer to 64 bit computing in general or does it represent a
particular *brand* of 64 bit processors designed by Intel (ala "Pentium" or
"386")?
Thanks,
Dave|||http://en.wikipedia.org/wiki/X64
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:x_SdnandWO39lEjenZ2dnUVZ_tidnZ2d@.giganews.com...
>> However 64 bit systems are not automatically better here. X64 servers
>> use basically the same system boards as 32-bit systems.
> Hi David,
> Could you expand on this a bit? Excuse my ignorance here, but what do
> you mean when you say that X64 servers use basically the same system
> boards as 32 bit systems? How is that possible? Also, is "X64" just a
> generic term that's used to refer to 64 bit computing in general or does
> it represent a particular *brand* of 64 bit processors designed by Intel
> (ala "Pentium" or "386")?
> Thanks,
> Dave
>

Benefits of 64bit SQL?

Hi,
I'm trying to decide whether our next database server should be 32 or 64
bit. Could someone please explain the benefits of 64bit computing and the
factors I should be looking at in order to determine whether it would be of
value to me?
The only benefit I'm aware of is the fact that memory beyond 4gigs can
be accessed directly -- but surely there must be other benefits as well. I
imagine that the speed at which data is transferred across the bus must be
doubled due to the fatter data path... but given that I'd still be limited
by the I/O speed of the drives, is the performance improvement even
relevant?
Sorry for the newbie questions. I just want to avoid having some slick
talking salesman sell us a 64bit machine if we don't really need it. I want
to know what questions to ask.
Thanks...
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well.
That's pretty much it. But x64 64 bit does not add any cost to servers.
Intel and AMD's server chips are (basically) all 64 bit chips.

>I imagine that the speed at which data is transferred across the bus must
>be doubled due to the fatter data path... but given that I'd still be
>limited by the I/O speed of the drives, is the performance improvement even
>relevant?
Memory bus speed is a very important performance factor for databse servers.
With several gigabytes of data cached, moving that data in and out of the
CPU is one of the major system bottlenecks. Large on-chip L2 cache helps
here too. However 64 bit systems are not automatically better here. X64
servers use basically the same system boards as 32-bit systems.

> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
You definitely want 64bit, since it doesn't really cost you anyting. You
still have to choose between x64 and IA64-based systems. Currently dollar
for dollar x64 is the performance king, but for certian very large workloads
you might need a big IA64 box.
David
|||from a performance point of view, for the same hardware and less then 4Gb
there is no difference.
above 4Gb there are small improvements at the DB level. but managing the
memory is more easier.
the performance improvement is at the SSIS & AS levels. with more then 4Gb
these 2 tools takes a big advantage of this memory.
the other advantage is at the OS level.
Standard x64 edition of windows support 32Gb while the 32bits version is
limited to 4Gb.
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>
|||http://www.microsoft.com/sql/techinf...vironment.mspx
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>
|||> However 64 bit systems are not automatically better here. X64 servers use
> basically the same system boards as 32-bit systems.
Hi David,
Could you expand on this a bit? Excuse my ignorance here, but what do
you mean when you say that X64 servers use basically the same system boards
as 32 bit systems? How is that possible? Also, is "X64" just a generic term
that's used to refer to 64 bit computing in general or does it represent a
particular *brand* of 64 bit processors designed by Intel (ala "Pentium" or
"386")?
Thanks,
Dave
|||http://en.wikipedia.org/wiki/X64
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:x_SdnandWO39lEjenZ2dnUVZ_tidnZ2d@.giganews.com ...
> Hi David,
> Could you expand on this a bit? Excuse my ignorance here, but what do
> you mean when you say that X64 servers use basically the same system
> boards as 32 bit systems? How is that possible? Also, is "X64" just a
> generic term that's used to refer to 64 bit computing in general or does
> it represent a particular *brand* of 64 bit processors designed by Intel
> (ala "Pentium" or "386")?
> Thanks,
> Dave
>

Benefits of 64bit SQL?

Hi,
I'm trying to decide whether our next database server should be 32 or 64
bit. Could someone please explain the benefits of 64bit computing and the
factors I should be looking at in order to determine whether it would be of
value to me?
The only benefit I'm aware of is the fact that memory beyond 4gigs can
be accessed directly -- but surely there must be other benefits as well. I
imagine that the speed at which data is transferred across the bus must be
doubled due to the fatter data path... but given that I'd still be limited
by the I/O speed of the drives, is the performance improvement even
relevant?
Sorry for the newbie questions. I just want to avoid having some slick
talking salesman sell us a 64bit machine if we don't really need it. I want
to know what questions to ask.
Thanks..."The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well.
That's pretty much it. But x64 64 bit does not add any cost to servers.
Intel and AMD's server chips are (basically) all 64 bit chips.

>I imagine that the speed at which data is transferred across the bus must
>be doubled due to the fatter data path... but given that I'd still be
>limited by the I/O speed of the drives, is the performance improvement even
>relevant?
Memory bus speed is a very important performance factor for databse servers.
With several gigabytes of data cached, moving that data in and out of the
CPU is one of the major system bottlenecks. Large on-chip L2 cache helps
here too. However 64 bit systems are not automatically better here. X64
servers use basically the same system boards as 32-bit systems.

> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
You definitely want 64bit, since it doesn't really cost you anyting. You
still have to choose between x64 and IA64-based systems. Currently dollar
for dollar x64 is the performance king, but for certian very large workloads
you might need a big IA64 box.
David|||from a performance point of view, for the same hardware and less then 4Gb
there is no difference.
above 4Gb there are small improvements at the DB level. but managing the
memory is more easier.
the performance improvement is at the SSIS & AS levels. with more then 4Gb
these 2 tools takes a big advantage of this memory.
the other advantage is at the OS level.
Standard x64 edition of windows support 32Gb while the 32bits version is
limited to 4Gb.
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>|||x" target="_blank">http://www.microsoft.com/sql/techin...nt.msp
x
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>|||> However 64 bit systems are not automatically better here. X64 servers use
> basically the same system boards as 32-bit systems.
Hi David,
Could you expand on this a bit? Excuse my ignorance here, but what do
you mean when you say that X64 servers use basically the same system boards
as 32 bit systems? How is that possible? Also, is "X64" just a generic term
that's used to refer to 64 bit computing in general or does it represent a
particular *brand* of 64 bit processors designed by Intel (ala "Pentium" or
"386")?
Thanks,
Dave|||http://en.wikipedia.org/wiki/X64
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:x_SdnandWO39lEjenZ2dnUVZ_tidnZ2d@.gi
ganews.com...
> Hi David,
> Could you expand on this a bit? Excuse my ignorance here, but what do
> you mean when you say that X64 servers use basically the same system
> boards as 32 bit systems? How is that possible? Also, is "X64" just a
> generic term that's used to refer to 64 bit computing in general or does
> it represent a particular *brand* of 64 bit processors designed by Intel
> (ala "Pentium" or "386")?
> Thanks,
> Dave
>

BEGIN TRAN . . . WITH MARK . . .

Hallo All,

Can somebody explain why the same function works different with MS SQL 2000 and MS SQL 2005?
On both systems 2000 and 2005 I have 2x databases named ACCT and PROD (actually only a test environment).
On both systems I try to execute the following statements:
BEGIN TRAN TRAN_01 WITH MARK 'My TRAN_01'
USE PROD
INSERT INTO [PROD].[dbo].[_PROT]([STR_COMMENT], [R_NUM_T1], [R_NUM_T2])
VALUES('PROT_COMMENT', 1004, 1004)
USE ACCT
INSERT INTO [ACCT].[dbo].[_PROT]([STR_COMMENT], [R_NUM_T1], [R_NUM_T2])
VALUES('PROT_COMMENT', 1004, 1004)
COMMIT TRAN TRAN_01
After executing the statements I start the following query:
SELECT * FROM [msdb].[dbo].[logmarkhistory]
On MS SQL 2000 I get as results:
PROD TRAN_01 My TRAN_01 SUPPORT\Administrator 3944000000107600001 2006-03-29 17:15:13.930
ACCT TRAN_01 My TRAN_01 SUPPORT\Administrator 8000000009200001 2006-03-29 17:15:13.930
Seems to be correct. I think it is the way it should work according to the documentation.

On MS SQL 2005 I only get the following results:
PROD TRAN_01 My TRAN_01 SU 29000000107800001 2006-03-29 17:31:32.283
There are no entries in the table for the ACCT database and the account / user_name is shown incorrectly.
It seems to be an ERROR in the processing of such marked transactions in MS SQL 2005.See the Books Online Topic "Ensuring Recoverability of Related Databases". I believe that there is a change in SQL Server 2005.|||Hello ALL,
I have the solution now.
It have nothing to do with some changes in SQL Server 2005.
It seems just to be the following. I habe never made a backup
of the ACCT database in the past. After I executed the full
online backup of the ACCT database for the first time I get
exactly the same results as with MS SQL 2000.

begin and end transaction and transaction log

Hello everyone,
This is more of an architectural question about SQL Server. Can
someone please explain why when I perform a query such as the one
below that updates a table using begin and end transaction I am unable
to programmatically truncate the transaction log. The only way I have
found to truncate the transaction log is to stop and start the SQL
Server Service. Does this transaction use the tempdb? Is that why I
am unable to truncate the transaction log? Is there a better way to
do this?

Begin trans T1

Update sometable
Set random_row = 'blah'

End trans T1

Thanks!Kruton (wmlyerly@.gmail.com) writes:

Quote:

Originally Posted by

This is more of an architectural question about SQL Server. Can
someone please explain why when I perform a query such as the one
below that updates a table using begin and end transaction I am unable
to programmatically truncate the transaction log. The only way I have
found to truncate the transaction log is to stop and start the SQL
Server Service. Does this transaction use the tempdb? Is that why I
am unable to truncate the transaction log? Is there a better way to
do this?
>
Begin trans T1
>
Update sometable
Set random_row = 'blah'
>
End trans T1

Why would you truncate the transaction log in the first place?

If you run with full recovery and want to be table to restore to a point
in time, the you should backup your transaction log regularly.

If you don't care about the point-in-time restores but are content with
restoring from a full backup in case of a failure, you should set the
database in simple recovery.

--
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|||Hi Erlang,
This is part of a large OLAP process that runs many times a day. I do
not want to / need to restore to a particular time. I have a dba that
does full backups on a regular basis. I would agree with you to a
certain extent if this were OLTP but it is not.

Thanks.

On Dec 12, 2:18 pm, Erland Sommarskog <esq...@.sommarskog.sewrote:

Quote:

Originally Posted by

Kruton (wmlye...@.gmail.com) writes:

Quote:

Originally Posted by

This is more of an architectural question about SQL Server. Can
someone please explain why when I perform a query such as the one
below that updates a table using begin and end transaction I am unable
to programmatically truncate the transaction log. The only way I have
found to truncate the transaction log is to stop and start the SQL
Server Service. Does this transaction use the tempdb? Is that why I
am unable to truncate the transaction log? Is there a better way to
do this?

>

Quote:

Originally Posted by

Begin trans T1

>

Quote:

Originally Posted by

Update sometable
Set random_row = 'blah'

>

Quote:

Originally Posted by

End trans T1

>
Why would you truncate the transaction log in the first place?
>
If you run with full recovery and want to be table to restore to a point
in time, the you should backup your transaction log regularly.
>
If you don't care about the point-in-time restores but are content with
restoring from a full backup in case of a failure, you should set the
database in simple recovery.
>
--
Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
>
Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx- Hide quoted text -
>
- Show quoted text -

|||"Kruton" <wmlyerly@.gmail.comwrote in message
news:a8d08495-59a1-4090-8906-2a9ff8b01945@.o42g2000hsc.googlegroups.com...

Quote:

Originally Posted by

Hi Erlang,
This is part of a large OLAP process that runs many times a day. I do
not want to / need to restore to a particular time. I have a dba that
does full backups on a regular basis. I would agree with you to a
certain extent if this were OLTP but it is not.

Then your DBA needs to set the DBA to simple recovery.

Quote:

Originally Posted by

>
Thanks.
>
On Dec 12, 2:18 pm, Erland Sommarskog <esq...@.sommarskog.sewrote:

Quote:

Originally Posted by

>Kruton (wmlye...@.gmail.com) writes:

Quote:

Originally Posted by

This is more of an architectural question about SQL Server. Can
someone please explain why when I perform a query such as the one
below that updates a table using begin and end transaction I am unable
to programmatically truncate the transaction log. The only way I have
found to truncate the transaction log is to stop and start the SQL
Server Service. Does this transaction use the tempdb? Is that why I
am unable to truncate the transaction log? Is there a better way to
do this?

>>

Quote:

Originally Posted by

Begin trans T1

>>

Quote:

Originally Posted by

Update sometable
Set random_row = 'blah'

>>

Quote:

Originally Posted by

End trans T1

>>
>Why would you truncate the transaction log in the first place?
>>
>If you run with full recovery and want to be table to restore to a point
>in time, the you should backup your transaction log regularly.
>>
>If you don't care about the point-in-time restores but are content with
>restoring from a full backup in case of a failure, you should set the
>database in simple recovery.
>>
>--
>Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
>>
>Books Online for SQL Server 2005
>athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
>Books Online for SQL Server 2000
>athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx- Hide
>quoted text -
>>
>- Show quoted text -

>

--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Kruton (wmlyerly@.gmail.com) writes:

Quote:

Originally Posted by

This is part of a large OLAP process that runs many times a day. I do
not want to / need to restore to a particular time. I have a dba that
does full backups on a regular basis. I would agree with you to a
certain extent if this were OLTP but it is not.

Then you need simple recovery. What I failed to say is that with simple
recovery, SQL Server will regularly truncate the transaction log, and thus
keep it in check. The one thing to keep in mind is that truncation never
goes past the open transaction, so if you have a long-running transaction
the log can grow never the less.

--
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|||Hi Erland,
This sounds like it could be it. I will give it a try. Thanks

On Dec 13, 12:21 am, Erland Sommarskog <esq...@.sommarskog.sewrote:

Quote:

Originally Posted by

Kruton (wmlye...@.gmail.com) writes:

Quote:

Originally Posted by

This is part of a large OLAP process that runs many times a day. I do
not want to / need to restore to a particular time. I have a dba that
does full backups on a regular basis. I would agree with you to a
certain extent if this were OLTP but it is not.

>
Then you need simple recovery. What I failed to say is that with simple
recovery, SQL Server will regularly truncate the transaction log, and thus
keep it in check. The one thing to keep in mind is that truncation never
goes past the open transaction, so if you have a long-running transaction
the log can grow never the less.
>
--
Erland Sommarskog, SQL Server MVP, esq...@.sommarskog.se
>
Books Online for SQL Server 2005 athttp://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books...
Books Online for SQL Server 2000 athttp://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

Before merging,validate subscribers with this expression

Hello,
Could someone explain me what it meens.
I have made 2 merge publications with dynamic filters: suser_sname()
The first one does not validate subcriber before the synchronisation
The second one validate with 'suser_sname()'
I do not see differences between the 2 replication, and i do not exactly
understand what it means.
Thank you.
Courtoisement
Pierre-Marie PETIT
pm@.nst.fr
03 20 06 63 94
can you script out your publication and subscription and post it here?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"pm" <pm@.nst.fr> wrote in message
news:uPfNCExnEHA.3428@.TK2MSFTNGP11.phx.gbl...
> Hello,
> Could someone explain me what it meens.
> I have made 2 merge publications with dynamic filters: suser_sname()
> The first one does not validate subcriber before the synchronisation
> The second one validate with 'suser_sname()'
> I do not see differences between the 2 replication, and i do not exactly
> understand what it means.
> Thank you.
> --
> Courtoisement
> Pierre-Marie PETIT
> pm@.nst.fr
> 03 20 06 63 94
>
|||Here is the only differences between the 2 publications
(you can see that it is only here: @.validate_subscriber_info =
N'suser_sname()' Thie parameters is not in the second Tsql code)
So i do not understand what is this parameter for @.validate_subscriber_info
exec sp_addmergepublication @.publication =
N'pub_SYNERGY_Dyn_UserFilter_validation', @.description = N'Pub avec Filtre
sur le user et validation des donnes', @.retention = 14, @.sync_mode =
N'native', @.allow_push = N'true', @.allow_pull = N'true', @.allow_anonymous =
N'false', @.enabled_for_internet = N'false', @.centralized_conflicts =
N'true', @.dynamic_filters = N'true', @.snapshot_in_defaultfolder = N'true',
@.compress_snapshot = N'false', @.ftp_port = 21, @.ftp_login = N'anonymous',
@.conflict_retention = 14, @.keep_partition_changes = N'true',
@.allow_subscription_copy = N'false', @.allow_synctoalternate = N'false',
@.validate_subscriber_info = N'suser_sname()', @.add_to_active_directory =
N'false', @.max_concurrent_merge = 0, @.max_concurrent_dynamic_snapshots = 0
exec sp_addmergepublication @.publication = N'pub_SYNERGY_Dyn_UserFilter',
@.description = N'Pub avec Filtre sur le user (qui ne doit pas faire partie
du compte admin de sql)', @.retention = 14, @.sync_mode = N'native',
@.allow_push = N'true', @.allow_pull = N'true', @.allow_anonymous = N'false',
@.enabled_for_internet = N'false', @.centralized_conflicts = N'true',
@.dynamic_filters = N'true', @.snapshot_in_defaultfolder = N'true',
@.compress_snapshot = N'false', @.ftp_port = 21, @.ftp_login = N'anonymous',
@.conflict_retention = 14, @.keep_partition_changes = N'true',
@.allow_subscription_copy = N'false', @.allow_synctoalternate = N'false',
@.add_to_active_directory = N'false', @.max_concurrent_merge = 0,
@.max_concurrent_dynamic_snapshots = 0
"Hilary Cotter" <hilary.cotter@.gmail.com> a crit dans le message de
news:%23cPKwUxnEHA.3396@.tk2msftngp13.phx.gbl...
> can you script out your publication and subscription and post it here?
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "pm" <pm@.nst.fr> wrote in message
> news:uPfNCExnEHA.3428@.TK2MSFTNGP11.phx.gbl...
>