Big Log file that won't shrink....

I have a fairly simple DB, One Log file, one data file, its got half a dozen tables in it that are used for a web based app that allows users to look each other up (think online telephone directory with a few extra bits and you are there), there's a data feed that adds new lines each day as users data changes or new people get added. But this is a couple of hundred or so lines a day, the tables hold about 40,000 data lines as we never delete data just retire it.

The problem is the main data file is about 200Mb, the Log file however is 3.8Gb. Now we did import and re-import various bits initially and clear down tables and such. But I don't understand why i can't shrink the log file. I've tried everything I can think of. I've even detached and re-attached the DB. Still no joy.

The file size/usage is

data file 200Mb size in use 117Mb

log file 3749.99Mb size in use 3719.89Mb

Anyone have any suggestions for things to look at?

many thanks

Steve

Hi,

look here:

http://www.aspfaq.com/show.asp?id=2471

HTH, Jens Suessmeyer.

http://www.sqlserver2005.de

Best way to launch report from a C# Winforms app?

I'm new to SSRS. I would like to launch a report from a C# desktop application, supplying parameters programatically. I was able to do this using System.Diagnostics.Process p ... then p.Start(@."(path)\iexplore.exe","(reportURL)"); I'm betting there's a much better way to do this.

Ideally I would like to create an IE window that shows only the report, that is, only the report viewer toolbar is visible, the IE toolbars and menus are hidden. I want to specify IE as the browser in case some other browser is installed as the default web browser.

Can anyone link me to a tutorial or provide a code snip? Thanks.Hi do not launch in IE. use ReportViewer Control to see that. You can add reports to your application by adding from Add Web Reference.|||Alas, it is at present still a .Net 1.1 application. I'll use ReportViewer when I upgrade it to .Net 2.0. In the meantime I'll launch IE to view the report. I tried to use SendKeys.Send to send F11 to get IE in fullscreen mode, but SetForegroundWindow did not work when given the Handle property of the process object returned by Process.Start.

Thanks for your response.

Best way to inform .NET app of change in DB content

Previously had a 'prototype' (.NET 1.0, SQL Server 2000, CCW to .NET) whereby an update trigger called out to our .NET app. Obvioulsy now SQL Server 2005 is nearly upon us I'd like to explore a better mechanism in order to consider the next phase of deployment (.NET 2, SQL Server 2005).

I have a number of servers that 'cache' data from a table in SQL Server. At some later time one of the servers may update a set of the data. When this occurs I'd like to alert the other servers that the data has changed so they can refresh/drop it from the local cache/ The data can cover a number of rows from one of the DB tables (depends on how the cache is configured). The table is simply a persistent object store.

With .NET being an integral part of SQL2005, does anyone have any guidance on how to achieve this efficiently. I'd like to think there would be a .NET event mechanism built in, but I've not seen anything like this!

Thanks in advance!You can use SQL Server Notification Services: http://www.devx.com/dbzone/Article/28522|||

You can use the SqlNotification class in .NET 2.0 - this can be used in both SQL Server 2000 and SQL Server 2005

|||

Thank you both for your answers! I had look at SQL Notification Services but wondered if this is too 'heavyweight' for my needs. I'll take a close look at the .NET 2 feature.

|||You can test it out by visiting http://msdn.demoservers.com and look for the SQL Server 2005 and ADO.NET hands-on lab as this covers using the SqlNotification and SqlDependency objects in .NET 2.0|||Look up topics on Query Notifications and SqlDependency in the 2005 MSDN Library. Note that these are not the same as Notification Services. They're much lighter-weight, and focused on firing application events rather than sending external notifications. -- Adam MachanicSQL Server MVPhttp://www.datamanipulation.net-- <adamhearn@.discussions..microsoft.com> wrote in message news:68627a2a-01ab-42f4-b950-54dd2e1a3041@.discussions.microsoft.com...Previously had a 'prototype' (.NET 1.0, SQL Server 2000, CCW to .NET) whereby an update trigger called out to our .NET app. Obvioulsy now SQL Server 2005 is nearly upon us I'd like to explore a better mechanism in order to consider the next phase of deployment (.NET 2, SQL Server 2005).I have a number of servers that 'cache' data from a table in SQL Server. At some later time one of the servers may update a set of the data. When this occurs I'd like to alert the other servers that the data has changed so they can refresh/drop it from the local cache/ The data can cover a number of rows from one of the DB tables (depends on how the cache is configured). The table is simply a persistent object store.With .NET being an integral part of SQL2005, does anyone have any guidance on how to achieve this efficiently. I'd like to think there would be a .NET event mechanism built in, but I've not seen anything like this!Thanks in advance!

Best way to inform .NET app of change in DB content

Previously had a 'prototype' (.NET 1.0, SQL Server 2000, CCW to .NET) whereby an update trigger called out to our .NET app. Obvioulsy now SQL Server 2005 is nearly upon us I'd like to explore a better mechanism in order to consider the next phase of deployment (.NET 2, SQL Server 2005).

I have a number of servers that 'cache' data from a table in SQL Server. At some later time one of the servers may update a set of the data. When this occurs I'd like to alert the other servers that the data has changed so they can refresh/drop it from the local cache/ The data can cover a number of rows from one of the DB tables (depends on how the cache is configured). The table is simply a persistent object store.

With .NET being an integral part of SQL2005, does anyone have any guidance on how to achieve this efficiently. I'd like to think there would be a .NET event mechanism built in, but I've not seen anything like this!

Thanks in advance!You can use SQL Server Notification Services: http://www.devx.com/dbzone/Article/28522|||

You can use the SqlNotification class in .NET 2.0 - this can be used in both SQL Server 2000 and SQL Server 2005

|||

Thank you both for your answers! I had look at SQL Notification Services but wondered if this is too 'heavyweight' for my needs. I'll take a close look at the .NET 2 feature.

|||You can test it out by visiting http://msdn.demoservers.com and look for the SQL Server 2005 and ADO.NET hands-on lab as this covers using the SqlNotification and SqlDependency objects in .NET 2.0|||Look up topics on Query Notifications and SqlDependency in the 2005 MSDN Library. Note that these are not the same as Notification Services. They're much lighter-weight, and focused on firing application events rather than sending external notifications. -- Adam MachanicSQL Server MVPhttp://www.datamanipulation.net-- <adamhearn@.discussions..microsoft.com> wrote in message news:68627a2a-01ab-42f4-b950-54dd2e1a3041@.discussions.microsoft.com...Previously had a 'prototype' (.NET 1.0, SQL Server 2000, CCW to .NET) whereby an update trigger called out to our .NET app. Obvioulsy now SQL Server 2005 is nearly upon us I'd like to explore a better mechanism in order to consider the next phase of deployment (.NET 2, SQL Server 2005).I have a number of servers that 'cache' data from a table in SQL Server. At some later time one of the servers may update a set of the data. When this occurs I'd like to alert the other servers that the data has changed so they can refresh/drop it from the local cache/ The data can cover a number of rows from one of the DB tables (depends on how the cache is configured). The table is simply a persistent object store.With .NET being an integral part of SQL2005, does anyone have any guidance on how to achieve this efficiently. I'd like to think there would be a .NET event mechanism built in, but I've not seen anything like this!Thanks in advance!

Best way to duplicate almost whole database (same data for next period scenario)

Hi there
I'm working on a budgeting app which will be used to prepare a budget
for a given period. In the beginning of the next period all data from
the previous one should be duplicated and inserted into a new period so
they would become a base for preparing new data (by updating old
values).
I think first thing should be adding PERIOD column to each table. Or
not each one? For example it wouldn't be necessary to put this column
into intermediary tables, since period value for each row could be
identified by their parent tables. But I'm afraid it could make things
less transparent.
Also, I think that it's more convenient to have natural composite
primary keys for such use instead of single surrogates, since I could
just duplicate each row and just update PERIOD column which would be
part of a composite key (and composite foreign key, hence). But not
always natural keys are possible, so I will have to find a solution to
preserve relationships anyway.
Do you have any suggestions, or could you show me some resources on the
scenario? Should I (in one big transaction) turn off check constraints
(for tables where foreign keys cannot be null), duplicate all tables
with updating the PERIOD column and then update foreign keys basing on
data from previous period (ie. insert into current row's foreign key
column(s) the id of current version of row which was related to
previous version of the current row)?
thanks for any suggestion and sorry for not being too clear.
greets
hpHP
What is the version are you using? I think you need read about partition in
the SQL Server 2000/2005
"HP" <ha5en1@.gmail.com> wrote in message
news:1164677515.886061.267820@.l12g2000cwl.googlegroups.com...
> Hi there
> I'm working on a budgeting app which will be used to prepare a budget
> for a given period. In the beginning of the next period all data from
> the previous one should be duplicated and inserted into a new period so
> they would become a base for preparing new data (by updating old
> values).
> I think first thing should be adding PERIOD column to each table. Or
> not each one? For example it wouldn't be necessary to put this column
> into intermediary tables, since period value for each row could be
> identified by their parent tables. But I'm afraid it could make things
> less transparent.
>
> Also, I think that it's more convenient to have natural composite
> primary keys for such use instead of single surrogates, since I could
> just duplicate each row and just update PERIOD column which would be
> part of a composite key (and composite foreign key, hence). But not
> always natural keys are possible, so I will have to find a solution to
> preserve relationships anyway.
> Do you have any suggestions, or could you show me some resources on the
> scenario? Should I (in one big transaction) turn off check constraints
> (for tables where foreign keys cannot be null), duplicate all tables
> with updating the PERIOD column and then update foreign keys basing on
> data from previous period (ie. insert into current row's foreign key
> column(s) the id of current version of row which was related to
> previous version of the current row)?
> thanks for any suggestion and sorry for not being too clear.
> greets
> hp
>|||> What is the version are you using? I think you need read about partition in
> the SQL Server 2000/2005
it's 2k, sorry.
thanks for info, I'm reading about it at the moment. isn't it a
warehose solution? wouldn't it be an overkill for normal db where
performance isn't so important? or is there a way in which partitions
would make abovementioned operations more convenient?
thanks a lot
hp

Best way to duplicate almost whole database (same data for next period scenario)

Hi there
I'm working on a budgeting app which will be used to prepare a budget
for a given period. In the beginning of the next period all data from
the previous one should be duplicated and inserted into a new period so
they would become a base for preparing new data (by updating old
values).
I think first thing should be adding PERIOD column to each table. Or
not each one? For example it wouldn't be necessary to put this column
into intermediary tables, since period value for each row could be
identified by their parent tables. But I'm afraid it could make things
less transparent.
Also, I think that it's more convenient to have natural composite
primary keys for such use instead of single surrogates, since I could
just duplicate each row and just update PERIOD column which would be
part of a composite key (and composite foreign key, hence). But not
always natural keys are possible, so I will have to find a solution to
preserve relationships anyway.
Do you have any suggestions, or could you show me some resources on the
scenario? Should I (in one big transaction) turn off check constraints
(for tables where foreign keys cannot be null), duplicate all tables
with updating the PERIOD column and then update foreign keys basing on
data from previous period (ie. insert into current row's foreign key
column(s) the id of current version of row which was related to
previous version of the current row)?
thanks for any suggestion and sorry for not being too clear.
greets
hp
HP
What is the version are you using? I think you need read about partition in
the SQL Server 2000/2005
"HP" <ha5en1@.gmail.com> wrote in message
news:1164677515.886061.267820@.l12g2000cwl.googlegr oups.com...
> Hi there
> I'm working on a budgeting app which will be used to prepare a budget
> for a given period. In the beginning of the next period all data from
> the previous one should be duplicated and inserted into a new period so
> they would become a base for preparing new data (by updating old
> values).
> I think first thing should be adding PERIOD column to each table. Or
> not each one? For example it wouldn't be necessary to put this column
> into intermediary tables, since period value for each row could be
> identified by their parent tables. But I'm afraid it could make things
> less transparent.
>
> Also, I think that it's more convenient to have natural composite
> primary keys for such use instead of single surrogates, since I could
> just duplicate each row and just update PERIOD column which would be
> part of a composite key (and composite foreign key, hence). But not
> always natural keys are possible, so I will have to find a solution to
> preserve relationships anyway.
> Do you have any suggestions, or could you show me some resources on the
> scenario? Should I (in one big transaction) turn off check constraints
> (for tables where foreign keys cannot be null), duplicate all tables
> with updating the PERIOD column and then update foreign keys basing on
> data from previous period (ie. insert into current row's foreign key
> column(s) the id of current version of row which was related to
> previous version of the current row)?
> thanks for any suggestion and sorry for not being too clear.
> greets
> hp
>
|||
> What is the version are you using? I think you need read about partition in
> the SQL Server 2000/2005
it's 2k, sorry.
thanks for info, I'm reading about it at the moment. isn't it a
warehose solution? wouldn't it be an overkill for normal db where
performance isn't so important? or is there a way in which partitions
would make abovementioned operations more convenient?
thanks a lot
hp

Best way to duplicate almost whole database (same data for next period scenario)

Hi there
I'm working on a budgeting app which will be used to prepare a budget
for a given period. In the beginning of the next period all data from
the previous one should be duplicated and inserted into a new period so
they would become a base for preparing new data (by updating old
values).
I think first thing should be adding PERIOD column to each table. Or
not each one? For example it wouldn't be necessary to put this column
into intermediary tables, since period value for each row could be
identified by their parent tables. But I'm afraid it could make things
less transparent.
Also, I think that it's more convenient to have natural composite
primary keys for such use instead of single surrogates, since I could
just duplicate each row and just update PERIOD column which would be
part of a composite key (and composite foreign key, hence). But not
always natural keys are possible, so I will have to find a solution to
preserve relationships anyway.
Do you have any suggestions, or could you show me some resources on the
scenario? Should I (in one big transaction) turn off check constraints
(for tables where foreign keys cannot be null), duplicate all tables
with updating the PERIOD column and then update foreign keys basing on
data from previous period (ie. insert into current row's foreign key
column(s) the id of current version of row which was related to
previous version of the current row)?
thanks for any suggestion and sorry for not being too clear.
greets
hpHP
What is the version are you using? I think you need read about partition in
the SQL Server 2000/2005
"HP" <ha5en1@.gmail.com> wrote in message
news:1164677515.886061.267820@.l12g2000cwl.googlegroups.com...
> Hi there
> I'm working on a budgeting app which will be used to prepare a budget
> for a given period. In the beginning of the next period all data from
> the previous one should be duplicated and inserted into a new period so
> they would become a base for preparing new data (by updating old
> values).
> I think first thing should be adding PERIOD column to each table. Or
> not each one? For example it wouldn't be necessary to put this column
> into intermediary tables, since period value for each row could be
> identified by their parent tables. But I'm afraid it could make things
> less transparent.
>
> Also, I think that it's more convenient to have natural composite
> primary keys for such use instead of single surrogates, since I could
> just duplicate each row and just update PERIOD column which would be
> part of a composite key (and composite foreign key, hence). But not
> always natural keys are possible, so I will have to find a solution to
> preserve relationships anyway.
> Do you have any suggestions, or could you show me some resources on the
> scenario? Should I (in one big transaction) turn off check constraints
> (for tables where foreign keys cannot be null), duplicate all tables
> with updating the PERIOD column and then update foreign keys basing on
> data from previous period (ie. insert into current row's foreign key
> column(s) the id of current version of row which was related to
> previous version of the current row)?
> thanks for any suggestion and sorry for not being too clear.
> greets
> hp
>|||
> What is the version are you using? I think you need read about partition
in
> the SQL Server 2000/2005
it's 2k, sorry.
thanks for info, I'm reading about it at the moment. isn't it a
warehose solution? wouldn't it be an overkill for normal db where
performance isn't so important? or is there a way in which partitions
would make abovementioned operations more convenient?
thanks a lot
hp