exponential values in the report

Hi,

I am values in scientific notation when i am rendering the report into excel.

I wanted the number to be displayed as it is without any scientific notation(exponential format)

Thanks in advance

Nalini

This is generally a formatting problem.

Can you give an example of one of the values that is rendering this way in Excel? Tell us:

* -- what is the real data value and type as it appears in the dataset

* -- what is the expression you are currently using in the RDL to display this expression

>L<

|||

Hi Lisa,

Thanks for the reply

The value which is being displayed is 2E+09

But when we go to the actual value it is 1506500000

One more example in this regard would be 5E+10 and the actual value is 50512086334

The data type in the table is numeric(22,3)

The value given above is a calculated value and is SUM of such fields.

The preview is beign displayed with the normal values but this problem arises when i render them to excel.

Thanks in advance,

Nalini

|||

OK, I did some simple tests with your value

SELECT cast(50512086334 AS numeric(22,3))

... and it looks like all you need to do to fix this is to *widen* the column. If you try widening the column directly in Excel, you'll see what I mean. But you probably should just widen that column slightly in the original report layout to resolve this. I realize that it displays okay in the unexported version, but Excel apparently needs a bit more room <s>.

HTH,

>L<

exponential value

I am using data flow. source is ole db and target is flat file (csv). I run sql server stored procedure in source and mapped all columns to target file.

Value "-5.0000000000000003E-2" is giving me hard time. It's coming in target file how can remove exponential before writing to target file. In source table that value is coming from float type column. I would like to use some function in select sql if I can.

Thank you - Ashok

Well, that is not a "number" (it's text), so of course you're going to have problems.

How are you extracting from the source table? Do you really need precision to 1e-16? Perhaps you should apply some bounds to the source data before extracting. I think in any application, the value of -0.05 would be appropriate in your case.|||

sorry it's just -5.0000000000000003E-2

I should not have put " in my question.

I have simple select sql in stored procedure which gets that data some thing like select qty from tablename

You are correct I just want -0.05 in my target file.

|||The fact there is an "E" in your data (not to mention the second negative sign) indicates to any parser that the data is text -- most likely.

Regardless, you should convert the data in your SQL statement. Something like this perhaps: (would give you 4 decimal places)

SELECT CAST(qty as decimal(20,4)) as qty
FROM tablename|||

I used CAST(endqty as DECIMAL(10,4)) AS Quantity,in my sql but still get -5.0000000000000003E-2 value in my target file. Looks nothing working I tried to create new table with endqty decimal(18,3) and select from that table but same. when I run stored procedure in management studio I see -0.0500 but in file it not coming same.

when i looked in connection of the .csv file data type is double-precision float [DT_R8] but this is all generated I have not changed any .

Thanks - Ashok

Now I tried change to decimal [DT_DECIMAL] in csv connection for Quantity still same result.

|||

Ashok Ojha wrote:

I used CAST(endqty as DECIMAL(10,4)) AS Quantity,in my sql but still get -5.0000000000000003E-2 value in my target file. Looks nothing working I tried to create new table with endqty decimal(18,3) and select from that table but same. when I run stored procedure in management studio I see -0.0500 but in file it not coming same.

when i looked in connection of the .csv file data type is double-precision float [DT_R8] but this is all generated I have not changed any .

Thanks - Ashok

I'd rebuild the source connections/data flows if possible, using the CAST statement in your source query.|||

I removed whole data flow and connection and strated again.

Now I am in Flat file connection manager edior -> columns and I see Quantity coming as -5.00000000000003E-2 which is not good

when I go in Advanced - DataType I see numeric [DT_NUMERIC] data precision 10 data scale 4

in preview also Quantity coming as -5.00000000000003E-2

Lets see what happen when I run.

You are the man. worked. in target file -.0500

THANK YOU - Phil Brammer
.

Exponential performance degradation with openxml the larger the message

Can anyone shed light on this?
I have been experiencing exponentially bad performance with OPENXML the
larger the xml message gets that it is processing. I have used SQL Profiler
to check what it going on - and it becomes obvious that SQL Server is stuck
at the OPENXML clause.
The table below shows this for 5000, 10000, and 20000 records. After the
table I have included the actual transact sql code that was in the profiler
at which it took that amount of time to process. The transact sql is loading
the XML in to a table variable.
The XML has a fairly flat structure. Nothing startling.
Please help. Its such a shame because OPENXML has been working so well for
us. I have also tried it on 100,000 records but the time it took to process
went through the roof!
records millis seconds minutes
-- -- -- --
20,000 122036 122 2.03
10,000 34169 34 0.57
5,000 10636 11 0.18
insert @.supplies
(
BranchNumber ,
RetailerCode ,
TitleCode ,
IssueYear ,
IssueNumber ,
InitialOrder ,
MainSupply ,
MainSupplyDate ,
TotalSupplyWithClaims ,
TotalReturns,
PmIndicator
)
select
BranchNumber,
RetailerCode,
TitleCode,
IssueYear,
IssueNumber,
InitialOrder,
MainSupply,
MainSupplyDate,
TotalSupplyWithClaims,
TotalReturns,
case lower ( PmIndicator ) when 'true' then 1 else 0 end
from
OPENXML ( @.iDoc, @.supplyXPath, 1 )
with
(
BranchNumber smallint '../@.Number',
RetailerCode smallint '@.RetailerCode',
TitleCode smallint '@.TitleCode',
IssueYear smallint '@.IssueYear',
IssueNumber smallint '@.IssueNumber',
InitialOrder integer '@.InitialOrder',
MainSupply integer '@.MainSupply',
MainSupplyDate datetime '@.MainSupplyDate',
TotalSupplyWithClaims integer '@.TotalSupplyWithClaims',
TotalReturns integer '@.TotalReturns',
PmIndicator varchar ( 5 ) '@.PmIndicator'
)Hah! Found out the reason why...
its all because of this:../@.Number
Simply referencing the parent element made OPENXML run over 10 times slower!
As soon as I flattened the XML by one level, in effect negating the need to
get the Number value from the parent, OPENXML flew like a rocket!
Get a load of this: processing 20,000 records was taking 122 seconds and now
it takes 8.
A warning to everyone therefore: if you are working with large XML documents
then don't reference a parent element, make sure your xml is very flat!!!
"Xerox" <info@.thinkscape.com> wrote in message
news:#8TgOmoJFHA.2772@.TK2MSFTNGP14.phx.gbl...
> Can anyone shed light on this?
> I have been experiencing exponentially bad performance with OPENXML the
> larger the xml message gets that it is processing. I have used SQL
Profiler
> to check what it going on - and it becomes obvious that SQL Server is
stuck
> at the OPENXML clause.
> The table below shows this for 5000, 10000, and 20000 records. After the
> table I have included the actual transact sql code that was in the
profiler
> at which it took that amount of time to process. The transact sql is
loading
> the XML in to a table variable.
> The XML has a fairly flat structure. Nothing startling.
> Please help. Its such a shame because OPENXML has been working so well for
> us. I have also tried it on 100,000 records but the time it took to
process
> went through the roof!
>
> records millis seconds minutes
> -- -- -- --
> 20,000 122036 122 2.03
> 10,000 34169 34 0.57
> 5,000 10636 11 0.18
>
> insert @.supplies
> (
> BranchNumber ,
> RetailerCode ,
> TitleCode ,
> IssueYear ,
> IssueNumber ,
> InitialOrder ,
> MainSupply ,
> MainSupplyDate ,
> TotalSupplyWithClaims ,
> TotalReturns,
> PmIndicator
> )
> select
> BranchNumber,
> RetailerCode,
> TitleCode,
> IssueYear,
> IssueNumber,
> InitialOrder,
> MainSupply,
> MainSupplyDate,
> TotalSupplyWithClaims,
> TotalReturns,
> case lower ( PmIndicator ) when 'true' then 1 else 0 end
> from
> OPENXML ( @.iDoc, @.supplyXPath, 1 )
> with
> (
> BranchNumber smallint '../@.Number',
> RetailerCode smallint '@.RetailerCode',
> TitleCode smallint '@.TitleCode',
> IssueYear smallint '@.IssueYear',
> IssueNumber smallint '@.IssueNumber',
> InitialOrder integer '@.InitialOrder',
> MainSupply integer '@.MainSupply',
> MainSupplyDate datetime '@.MainSupplyDate',
> TotalSupplyWithClaims integer '@.TotalSupplyWithClaims',
> TotalReturns integer '@.TotalReturns',
> PmIndicator varchar ( 5 ) '@.PmIndicator'
> )
>|||Thanks "Xerox"
This is indeed one of the caveats of using OpenXML that has to do with how
parent axes are implemented by the XPath engine.
If you cannot flatten, you could also use two OpenXML calls and use the
@.mp:id and @.mp:parentid metaproperties to then be able to join the data
together.
Best regards
Michael
"Xerox" <info@.thinkscape.com> wrote in message
news:OjWfW%23oJFHA.3500@.TK2MSFTNGP14.phx.gbl...
> Hah! Found out the reason why...
> its all because of this:../@.Number
> Simply referencing the parent element made OPENXML run over 10 times
> slower!
> As soon as I flattened the XML by one level, in effect negating the need
> to
> get the Number value from the parent, OPENXML flew like a rocket!
> Get a load of this: processing 20,000 records was taking 122 seconds and
> now
> it takes 8.
> A warning to everyone therefore: if you are working with large XML
> documents
> then don't reference a parent element, make sure your xml is very flat!!!
>
> "Xerox" <info@.thinkscape.com> wrote in message
> news:#8TgOmoJFHA.2772@.TK2MSFTNGP14.phx.gbl...
> Profiler
> stuck
> profiler
> loading
> process
>sql

Exponential performance degradation with openxml the larger the message

Can anyone shed light on this?
I have been experiencing exponentially bad performance with OPENXML the
larger the xml message gets that it is processing. I have used SQL Profiler
to check what it going on - and it becomes obvious that SQL Server is stuck
at the OPENXML clause.
The table below shows this for 5000, 10000, and 20000 records. After the
table I have included the actual transact sql code that was in the profiler
at which it took that amount of time to process. The transact sql is loading
the XML in to a table variable.
The XML has a fairly flat structure. Nothing startling.
Please help. Its such a shame because OPENXML has been working so well for
us. I have also tried it on 100,000 records but the time it took to process
went through the roof!
records millis seconds minutes
-- -- -- --
20,000 122036 122 2.03
10,000 34169 34 0.57
5,000 10636 11 0.18
insert @.supplies
(
BranchNumber ,
RetailerCode ,
TitleCode ,
IssueYear ,
IssueNumber ,
InitialOrder ,
MainSupply ,
MainSupplyDate ,
TotalSupplyWithClaims ,
TotalReturns,
PmIndicator
)
select
BranchNumber,
RetailerCode,
TitleCode,
IssueYear,
IssueNumber,
InitialOrder,
MainSupply,
MainSupplyDate,
TotalSupplyWithClaims,
TotalReturns,
case lower ( PmIndicator ) when 'true' then 1 else 0 end
from
OPENXML ( @.iDoc, @.supplyXPath, 1 )
with
(
BranchNumber smallint '../@.Number',
RetailerCode smallint '@.RetailerCode',
TitleCode smallint '@.TitleCode',
IssueYear smallint '@.IssueYear',
IssueNumber smallint '@.IssueNumber',
InitialOrder integer '@.InitialOrder',
MainSupply integer '@.MainSupply',
MainSupplyDate datetime '@.MainSupplyDate',
TotalSupplyWithClaims integer '@.TotalSupplyWithClaims',
TotalReturns integer '@.TotalReturns',
PmIndicator varchar ( 5 ) '@.PmIndicator'
)
Hah! Found out the reason why...
its all because of this:../@.Number
Simply referencing the parent element made OPENXML run over 10 times slower!
As soon as I flattened the XML by one level, in effect negating the need to
get the Number value from the parent, OPENXML flew like a rocket!
Get a load of this: processing 20,000 records was taking 122 seconds and now
it takes 8.
A warning to everyone therefore: if you are working with large XML documents
then don't reference a parent element, make sure your xml is very flat!!!
"Xerox" <info@.thinkscape.com> wrote in message
news:#8TgOmoJFHA.2772@.TK2MSFTNGP14.phx.gbl...
> Can anyone shed light on this?
> I have been experiencing exponentially bad performance with OPENXML the
> larger the xml message gets that it is processing. I have used SQL
Profiler
> to check what it going on - and it becomes obvious that SQL Server is
stuck
> at the OPENXML clause.
> The table below shows this for 5000, 10000, and 20000 records. After the
> table I have included the actual transact sql code that was in the
profiler
> at which it took that amount of time to process. The transact sql is
loading
> the XML in to a table variable.
> The XML has a fairly flat structure. Nothing startling.
> Please help. Its such a shame because OPENXML has been working so well for
> us. I have also tried it on 100,000 records but the time it took to
process
> went through the roof!
>
> records millis seconds minutes
> -- -- -- --
> 20,000 122036 122 2.03
> 10,000 34169 34 0.57
> 5,000 10636 11 0.18
>
> insert @.supplies
> (
> BranchNumber ,
> RetailerCode ,
> TitleCode ,
> IssueYear ,
> IssueNumber ,
> InitialOrder ,
> MainSupply ,
> MainSupplyDate ,
> TotalSupplyWithClaims ,
> TotalReturns,
> PmIndicator
> )
> select
> BranchNumber,
> RetailerCode,
> TitleCode,
> IssueYear,
> IssueNumber,
> InitialOrder,
> MainSupply,
> MainSupplyDate,
> TotalSupplyWithClaims,
> TotalReturns,
> case lower ( PmIndicator ) when 'true' then 1 else 0 end
> from
> OPENXML ( @.iDoc, @.supplyXPath, 1 )
> with
> (
> BranchNumber smallint '../@.Number',
> RetailerCode smallint '@.RetailerCode',
> TitleCode smallint '@.TitleCode',
> IssueYear smallint '@.IssueYear',
> IssueNumber smallint '@.IssueNumber',
> InitialOrder integer '@.InitialOrder',
> MainSupply integer '@.MainSupply',
> MainSupplyDate datetime '@.MainSupplyDate',
> TotalSupplyWithClaims integer '@.TotalSupplyWithClaims',
> TotalReturns integer '@.TotalReturns',
> PmIndicator varchar ( 5 ) '@.PmIndicator'
> )
>
|||Thanks "Xerox"
This is indeed one of the caveats of using OpenXML that has to do with how
parent axes are implemented by the XPath engine.
If you cannot flatten, you could also use two OpenXML calls and use the
@.mp:id and @.mp:parentid metaproperties to then be able to join the data
together.
Best regards
Michael
"Xerox" <info@.thinkscape.com> wrote in message
news:OjWfW%23oJFHA.3500@.TK2MSFTNGP14.phx.gbl...
> Hah! Found out the reason why...
> its all because of this:../@.Number
> Simply referencing the parent element made OPENXML run over 10 times
> slower!
> As soon as I flattened the XML by one level, in effect negating the need
> to
> get the Number value from the parent, OPENXML flew like a rocket!
> Get a load of this: processing 20,000 records was taking 122 seconds and
> now
> it takes 8.
> A warning to everyone therefore: if you are working with large XML
> documents
> then don't reference a parent element, make sure your xml is very flat!!!
>
> "Xerox" <info@.thinkscape.com> wrote in message
> news:#8TgOmoJFHA.2772@.TK2MSFTNGP14.phx.gbl...
> Profiler
> stuck
> profiler
> loading
> process
>

Exponential Moving Avg.

Exponential Moving avg is calculated using the formula.
EMA = (Today's Price)* K + (EMA yesterday) * (1-K)
where K = 2 / (N+1)
The user is going to Input the K.

It is something like
F(N) = Price * K + F(N-1) * (1-K)

How can I reference, the previously calculated value in the Next row
calculation. I need to implement this in SQL Server.

I created a Stored procedure to do this and I used a Temp tbale with
Identity.

Create Table #TempMovAvg
(MID int identity(1,1) Primary key, tempDate DateTime, tValue float)

I Populate the data for that temp table using the below query.

Insert Into #TempMovAvg (tempDate, tValue)
Select Date, Price From DataTable

I tried Diff options to calculate the exponential Moving Avg using the
above formula, but none of them are giving the correct answers. I am
not able to reference the Prev Calculated value in the Next row
calculation.

Some queries I used.
Select a.TempDate, a.tValue,0.9*A.tValue+0.1*
(Select 0.9*t1.tValue+0.1*t2.tValue From #TempMovAvg t1, #TempMovAvg
t2 Where t1.MID=A.MID and t2.MID=t1.MID-1)
FROM #TempMovAvg A
Where A.MID>=2
order by a.TempDate

SELECT A.MId,
SUM(CASE WHEN B.MID=A.MID THEN 0.9*B.tValue
ELSE 0.1*A.tValue END) exponential_average
FROM #TempMovAvg A, #TempMovAvg B
WHERE A.MID>=2 AND A.MID BETWEEN B.MID AND B.MID+1
GROUP BY A.MID

Any help will be greatly appreciated.

thanks
Ganesh> Exponential Moving avg is calculated using the formula.
> EMA = (Today's Price)* K + (EMA yesterday) * (1-K)
> where K = 2 / (N+1)
> The user is going to Input the K.

Here is a version of the aggregate product function in SQL. You will
need to have the logorithm and exponential functions. They are not
standard, but they are very common.

The idea is that there are three special cases - all positive numbers,
one or more zeroes, and some negative numbers in the set.
You can find out what your situation is with a quick test on the
sign() of the minimum value in the set.

Within the case where you have negative numbers, there are two
sub-cases: (1) an even number of negatives or (2) an odd number of
negatives. You then need to apply some High School algebra to
determine the sign of the final result.

SELECT CASE MIN (SIGN(nbr))
WHEN 1 THEN EXP(SUM(LN(nbr))) -- all positive numbers
WHEN 0 THEN 0.00 -- some zeroes
WHEN -1 -- some negative numbers
THEN (EXP(SUM(LN(ABS(nbr))))
* (CASE WHEN
MOD (SUM(ABS(SIGN(nbr)-1)/ 2)), 2) = 1
THEN -1.00 ELSE 1.00 END)
ELSE NULL END AS big_pi
FROM NumberTable;

You will need to have the logarithm, exponential, mod and sign
functions in your SQL product. They are not standards, but they are
very common.

The idea is that there are three special cases - all positive numbers,
one or more zeros, and some negative numbers in the set. You can find
out what your situation is with a quick test on the sign() of the
minimum value in the set.

Within the case where you have negative numbers, there are two
sub-cases: (1) an even number of negatives or (2) an odd number of
negatives. You then need to apply some High School algebra to
determine the sign of the final result.

Itzak Ben-Gan had problems in implementing this in SQL Server that are
worth passing along in case your SQL product also has them. The query
as written returns a domain error in SQL Server, even though it should
not had the result expressions in the CASE expression been evaluated
<i>after<i> the conditional flow had performed a short circuit
evaluation. Examining the execution plan of the above query, it
looks like the optimizer evaluates all of the possible result
expressions in a step prior to handling the flow of the CASE
expression.

This means that in the expression after WHEN 1 ... the LN() function
is also invoked in an intermediate phase for zeros and negative
numbers, and in the expression after WHEN -1 ... the LN(ABS()) is
also invoked in an intermediate phase for 0's. This explains the
domain error.

To handle this, I had to use the ABS() and NULLIF() functions in the
positive numbers when CLAUSE, and the NULLIF() function in the
negative numbers when CLAUSE:

...
WHEN 1 THEN EXP(SUM(LN(ABS(NULLIF(result, 0.00)))))
and
...
WHEN -1
THEN EXP(SUM(LN(ABS(NULLIF(result, 0.00)))))
* CASE ...

Exponential Growth in SQL log files (.LDF)

We have a customer running our software that is experiencing a strange
occurence. We have thousands of customers and this is the only one that
has this issue. Recently, we upgraded him from using MSDE to Full SQL.
Since, any time he performs certain tasks in our software, the log file
will grow by the GB before our eyes until it fill the drive and shuts
down. We have exhausted our ideas as to what could be causing this. We
have configured all of the options for maximum efficiency. We are
band-aiding the problem by regularly deleting the log file and
generating a new one upon reconnecting. Has anyone else had a similar
experience with SQL that might provide some leads?
Doug wrote:
> We have a customer running our software that is experiencing a strange
> occurence. We have thousands of customers and this is the only one that
> has this issue. Recently, we upgraded him from using MSDE to Full SQL.
> Since, any time he performs certain tasks in our software, the log file
> will grow by the GB before our eyes until it fill the drive and shuts
> down. We have exhausted our ideas as to what could be causing this. We
> have configured all of the options for maximum efficiency.
What recovery model are you / they using?

> We are
> band-aiding the problem by regularly deleting the log file and
> generating a new one upon reconnecting. Has anyone else had a similar
> experience with SQL that might provide some leads?
Um, that's a strange way to limit growth of TX log. The usual approach
is to have regular backups. If you don't do that, you can at least use
BACKUP <db> LOG WITH NO_LOG and DBCC SHRINKFILE (see BOL).
Kind regards
robert
|||Does the log growth happen when he "performs certain tasks" or does it occur
off hours (perhaps when you have jobs such as database maintenance plans
scheduled)?
What recovery model is the database using?
What is your database backup strategy?
Keith Kratochvil
"Doug" <dclark@.cyrious.com> wrote in message
news:1143216876.301135.47350@.u72g2000cwu.googlegro ups.com...
> We have a customer running our software that is experiencing a strange
> occurence. We have thousands of customers and this is the only one that
> has this issue. Recently, we upgraded him from using MSDE to Full SQL.
> Since, any time he performs certain tasks in our software, the log file
> will grow by the GB before our eyes until it fill the drive and shuts
> down. We have exhausted our ideas as to what could be causing this. We
> have configured all of the options for maximum efficiency. We are
> band-aiding the problem by regularly deleting the log file and
> generating a new one upon reconnecting. Has anyone else had a similar
> experience with SQL that might provide some leads?
>

Exponential Growth in SQL log files (.LDF)

We have a customer running our software that is experiencing a strange
occurence. We have thousands of customers and this is the only one that
has this issue. Recently, we upgraded him from using MSDE to Full SQL.
Since, any time he performs certain tasks in our software, the log file
will grow by the GB before our eyes until it fill the drive and shuts
down. We have exhausted our ideas as to what could be causing this. We
have configured all of the options for maximum efficiency. We are
band-aiding the problem by regularly deleting the log file and
generating a new one upon reconnecting. Has anyone else had a similar
experience with SQL that might provide some leads?Doug wrote:
> We have a customer running our software that is experiencing a strange
> occurence. We have thousands of customers and this is the only one that
> has this issue. Recently, we upgraded him from using MSDE to Full SQL.
> Since, any time he performs certain tasks in our software, the log file
> will grow by the GB before our eyes until it fill the drive and shuts
> down. We have exhausted our ideas as to what could be causing this. We
> have configured all of the options for maximum efficiency.
What recovery model are you / they using?
> We are
> band-aiding the problem by regularly deleting the log file and
> generating a new one upon reconnecting. Has anyone else had a similar
> experience with SQL that might provide some leads?
Um, that's a strange way to limit growth of TX log. The usual approach
is to have regular backups. If you don't do that, you can at least use
BACKUP <db> LOG WITH NO_LOG and DBCC SHRINKFILE (see BOL).
Kind regards
robert|||Does the log growth happen when he "performs certain tasks" or does it occur
off hours (perhaps when you have jobs such as database maintenance plans
scheduled)?
What recovery model is the database using?
What is your database backup strategy?
--
Keith Kratochvil
"Doug" <dclark@.cyrious.com> wrote in message
news:1143216876.301135.47350@.u72g2000cwu.googlegroups.com...
> We have a customer running our software that is experiencing a strange
> occurence. We have thousands of customers and this is the only one that
> has this issue. Recently, we upgraded him from using MSDE to Full SQL.
> Since, any time he performs certain tasks in our software, the log file
> will grow by the GB before our eyes until it fill the drive and shuts
> down. We have exhausted our ideas as to what could be causing this. We
> have configured all of the options for maximum efficiency. We are
> band-aiding the problem by regularly deleting the log file and
> generating a new one upon reconnecting. Has anyone else had a similar
> experience with SQL that might provide some leads?
>

Exponential Growth in SQL log files (.LDF)

We have a customer running our software that is experiencing a strange
occurence. We have thousands of customers and this is the only one that
has this issue. Recently, we upgraded him from using MSDE to Full SQL.
Since, any time he performs certain tasks in our software, the log file
will grow by the GB before our eyes until it fill the drive and shuts
down. We have exhausted our ideas as to what could be causing this. We
have configured all of the options for maximum efficiency. We are
band-aiding the problem by regularly deleting the log file and
generating a new one upon reconnecting. Has anyone else had a similar
experience with SQL that might provide some leads?Doug wrote:
> We have a customer running our software that is experiencing a strange
> occurence. We have thousands of customers and this is the only one that
> has this issue. Recently, we upgraded him from using MSDE to Full SQL.
> Since, any time he performs certain tasks in our software, the log file
> will grow by the GB before our eyes until it fill the drive and shuts
> down. We have exhausted our ideas as to what could be causing this. We
> have configured all of the options for maximum efficiency.
What recovery model are you / they using?

> We are
> band-aiding the problem by regularly deleting the log file and
> generating a new one upon reconnecting. Has anyone else had a similar
> experience with SQL that might provide some leads?
Um, that's a strange way to limit growth of TX log. The usual approach
is to have regular backups. If you don't do that, you can at least use
BACKUP <db> LOG WITH NO_LOG and DBCC SHRINKFILE (see BOL).
Kind regards
robert|||Does the log growth happen when he "performs certain tasks" or does it occur
off hours (perhaps when you have jobs such as database maintenance plans
scheduled)?
What recovery model is the database using?
What is your database backup strategy?
Keith Kratochvil
"Doug" <dclark@.cyrious.com> wrote in message
news:1143216876.301135.47350@.u72g2000cwu.googlegroups.com...
> We have a customer running our software that is experiencing a strange
> occurence. We have thousands of customers and this is the only one that
> has this issue. Recently, we upgraded him from using MSDE to Full SQL.
> Since, any time he performs certain tasks in our software, the log file
> will grow by the GB before our eyes until it fill the drive and shuts
> down. We have exhausted our ideas as to what could be causing this. We
> have configured all of the options for maximum efficiency. We are
> band-aiding the problem by regularly deleting the log file and
> generating a new one upon reconnecting. Has anyone else had a similar
> experience with SQL that might provide some leads?
>sql