Hello,
If i need to execute a trace, would be better to execute on the server
machine, or in another client station?
Is that impacts the server performance (executing on the server) ?
Thanks
BrazilLeast impact is a server side trace (obviously executing on the server - but
also defined as a server side trace).
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Leandro Loureiro dos Santos" <leandro@.email.com> wrote in message
news:erYn8KTrDHA.964@.TK2MSFTNGP10.phx.gbl...
> Hello,
> If i need to execute a trace, would be better to execute on the server
> machine, or in another client station?
> Is that impacts the server performance (executing on the server) ?
> Thanks
> Brazil
>
Showing posts with label client. Show all posts
Showing posts with label client. Show all posts
Wednesday, March 28, 2012
Friday, March 23, 2012
Running [dbo].[insertProjectDetails] ( @ProjectTitle = <DEFAULT>, @ProjectPeriod = <DEF
Running [dbo].[insertProjectDetails] ( @.ProjectTitle = <DEFAULT>, @.ProjectPeriod = <DEFAULT>, @.Client = <DEFAULT>, @.Position = <DEFAULT>, @.ProjectDescription = <DEFAULT>, @.Responsiblities = <DEFAULT>, @.OtherInformation = <DEFAULT> ).
Procedure or Function 'insertProjectDetails' expects parameter '@.ProjectTitle', which was not supplied.
No rows affected.
(0 row(s) returned)
@.RETURN_VALUE =
Finished running [dbo].[insertProjectDetails].
Can any body send solution for this error?
Running [dbo].[insertProjectDetails] ( @.ProjectTitle = <DEFAULT>, @.ProjectPeriod = <DEFAULT>, @.Client = <DEFAULT>, @.Position = <DEFAULT>, @.ProjectDescription = <DEFAULT>, @.Responsiblities = <DEFAULT>, @.OtherInformation = <DEFAULT> ).
Procedure or Function 'insertProjectDetails' expects parameter '@.ProjectTitle', which was not supplied.
No rows affected.
(0 row(s) returned)
@.RETURN_VALUE =
Finished running [dbo].[insertProjectDetails].
|||Could you explain what is the problem?
If the SP is expecting parameters such as Date or a string then make sure to pass when it is called, as the error is self-explanatory.
|||PLease do not post multiple (duplicate) threads for the same problem.|||Hi,
the projectTitle parameter does not have a default value, therefore SQL Server complains about the facts that no value is passed in. Either pass a value to the procedure or change the procedure to use a Default value if noone is passed in.
ALTER PROCEDURE SomeProc
(
@.SomeParamWithDefault INT = 1 --The = 1 is for the default.
)
HTH, Jens K. Suessmeyer.
http://www.sqlserver2005.de
Running [dbo].[insertProjectDetails] ( @ProjectTitle = <DEFAULT>, @ProjectPeriod = <
Running [dbo].[insertProjectDetails] ( @.ProjectTitle = <DEFAULT>, @.ProjectPeriod = <DEFAULT>, @.Client = <DEFAULT>, @.Position = <DEFAULT>, @.ProjectDescription = <DEFAULT>, @.Responsiblities = <DEFAULT>, @.OtherInformation = <DEFAULT> ).
Procedure or Function 'insertProjectDetails' expects parameter '@.ProjectTitle', which was not supplied.
No rows affected.
(0 row(s) returned)
@.RETURN_VALUE =
Finished running [dbo].[insertProjectDetails].
Can any body send solution for this error?
Running [dbo].[insertProjectDetails] ( @.ProjectTitle = <DEFAULT>, @.ProjectPeriod = <DEFAULT>, @.Client = <DEFAULT>, @.Position = <DEFAULT>, @.ProjectDescription = <DEFAULT>, @.Responsiblities = <DEFAULT>, @.OtherInformation = <DEFAULT> ).
Procedure or Function 'insertProjectDetails' expects parameter '@.ProjectTitle', which was not supplied.
No rows affected.
(0 row(s) returned)
@.RETURN_VALUE =
Finished running [dbo].[insertProjectDetails].
|||Could you explain what is the problem?
If the SP is expecting parameters such as Date or a string then make sure to pass when it is called, as the error is self-explanatory.
|||PLease do not post multiple (duplicate) threads for the same problem.|||Hi,
the projectTitle parameter does not have a default value, therefore SQL Server complains about the facts that no value is passed in. Either pass a value to the procedure or change the procedure to use a Default value if noone is passed in.
ALTER PROCEDURE SomeProc
(
@.SomeParamWithDefault INT = 1 --The = 1 is for the default.
)
HTH, Jens K. Suessmeyer.
http://www.sqlserver2005.de
Monday, March 12, 2012
run openquery(mdx) through a linked server
Hi,
I run openquery() from a client application(sql 2005) to query SSAS data(sql 2005) through a linked server(sql 2005), but I get the following error:
OLE DB provider "MSOLAP" for linked server "LINKEDMINING" returned message "An error was encountered in the transport layer.".
OLE DB provider "MSOLAP" for linked server "LINKEDMINING" returned message "The peer prematurely closed the connection.".
Msg 7303, Level 16, State 1, Procedure gettpdt, Line 3
Cannot initialize the data source object of OLE DB provider "MSOLAP" for linked server "LINKEDMINING".
And, I am sure that I have made the MSOLAP provider Allow inprocess.
What can i do for this. Please advise.
Can you connect to Analysis Services directly from SQL Server management studio, from the same machine as SQL Server?|||hi,
I have solved this problem, thank you
|||how did you solve it?|||How did you solve this problem?|||add the server as trusted server in Active Director
choose the option 'trust computer for delegation'
run openquery(mdx) through a linked server
Hi,
I run openquery() from a client application(sql 2005) to query SSAS data(sql 2005) through a linked server(sql 2005), but I get the following error:
OLE DB provider "MSOLAP" for linked server "LINKEDMINING" returned message "An error was encountered in the transport layer.".
OLE DB provider "MSOLAP" for linked server "LINKEDMINING" returned message "The peer prematurely closed the connection.".
Msg 7303, Level 16, State 1, Procedure gettpdt, Line 3
Cannot initialize the data source object of OLE DB provider "MSOLAP" for linked server "LINKEDMINING".
And, I am sure that I have made the MSOLAP provider Allow inprocess.
What can i do for this. Please advise.
Can you connect to Analysis Services directly from SQL Server management studio, from the same machine as SQL Server?|||hi,
I have solved this problem, thank you
|||how did you solve it?|||How did you solve this problem?|||add the server as trusted server in Active Director
choose the option 'trust computer for delegation'
run openquery(mdx) through a linked server
Hi,
I run openquery() from a client application(sql 2005) to query SSAS data(sql 2005) through a linked server(sql 2005), but I get the following error:
OLE DB provider "MSOLAP" for linked server "LINKEDMINING" returned message "An error was encountered in the transport layer.".
OLE DB provider "MSOLAP" for linked server "LINKEDMINING" returned message "The peer prematurely closed the connection.".
Msg 7303, Level 16, State 1, Procedure gettpdt, Line 3
Cannot initialize the data source object of OLE DB provider "MSOLAP" for linked server "LINKEDMINING".
And, I am sure that I have made the MSOLAP provider Allow inprocess.
What can i do for this. Please advise.
Can you connect to Analysis Services directly from SQL Server management studio, from the same machine as SQL Server?|||hi,
I have solved this problem, thank you
|||how did you solve it?|||How did you solve this problem?|||add the server as trusted server in Active Director
choose the option 'trust computer for delegation'
Friday, March 9, 2012
Run dynamic SQL in debugger, get sql dump
If memory serves there was a bug with the debugger where
if you run it from the client machine it would either not
work, or result in an error (sorry can't find the
Microsoft Page).
How I solved this is to run the debugger on the server.
One of the Great Ones, Uri, Narayana, Wayne, Dejan, Tibor,
Dan, Andrew or Adam could probably tell you the reason and
the fix.
Peter
"I favor the Civil Rights Act of 1964 and it must be
enforced at gunpoint if necessary."
Ronald Reagan
>--Original Message--
>
>Hi,
>One of our developer runs a stored procedure containing
dynamic SQL in
>T-SQL Debugger. She consistently gets error ( see below ):
>SqlDumpExceptionHandler: Process 73 generated fatal
exception c0000005
>EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating
this process.
>If she runs it without debugger, it runs fine. She checks
the code many
>times and can't find anything wrong in the code. We have
no idea what's
>wrong.
>The server is a SQL Server 2000 (SP3) on a Window 2000
with service pack
>4.
>Thank you.
>
>*** Sent via Developersdex http://www.codecomments.com
***
>Don't just participate in USENET...get rewarded for it!
>.
>
Thanx for the response.
She ran it on the server and got the same error.
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
if you run it from the client machine it would either not
work, or result in an error (sorry can't find the
Microsoft Page).
How I solved this is to run the debugger on the server.
One of the Great Ones, Uri, Narayana, Wayne, Dejan, Tibor,
Dan, Andrew or Adam could probably tell you the reason and
the fix.
Peter
"I favor the Civil Rights Act of 1964 and it must be
enforced at gunpoint if necessary."
Ronald Reagan
>--Original Message--
>
>Hi,
>One of our developer runs a stored procedure containing
dynamic SQL in
>T-SQL Debugger. She consistently gets error ( see below ):
>SqlDumpExceptionHandler: Process 73 generated fatal
exception c0000005
>EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating
this process.
>If she runs it without debugger, it runs fine. She checks
the code many
>times and can't find anything wrong in the code. We have
no idea what's
>wrong.
>The server is a SQL Server 2000 (SP3) on a Window 2000
with service pack
>4.
>Thank you.
>
>*** Sent via Developersdex http://www.codecomments.com
***
>Don't just participate in USENET...get rewarded for it!
>.
>
Thanx for the response.
She ran it on the server and got the same error.
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
Run dynamic SQL in debugger, get sql dump
If memory serves there was a bug with the debugger where
if you run it from the client machine it would either not
work, or result in an error (sorry can't find the
Microsoft Page).
How I solved this is to run the debugger on the server.
One of the Great Ones, Uri, Narayana, Wayne, Dejan, Tibor,
Dan, Andrew or Adam could probably tell you the reason and
the fix.
Peter
"I favor the Civil Rights Act of 1964 and it must be
enforced at gunpoint if necessary."
Ronald Reagan
>--Original Message--
>
>Hi,
>One of our developer runs a stored procedure containing
dynamic SQL in
>T-SQL Debugger. She consistently gets error ( see below ):
>SqlDumpExceptionHandler: Process 73 generated fatal
exception c0000005
>EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating
this process.
>If she runs it without debugger, it runs fine. She checks
the code many
>times and can't find anything wrong in the code. We have
no idea what's
>wrong.
>The server is a SQL Server 2000 (SP3) on a Window 2000
with service pack
>4.
>Thank you.
>
>*** Sent via Developersdex http://www.codecomments.com
***
>Don't just participate in USENET...get rewarded for it!
>.
>Thanx for the response.
She ran it on the server and got the same error.
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
if you run it from the client machine it would either not
work, or result in an error (sorry can't find the
Microsoft Page).
How I solved this is to run the debugger on the server.
One of the Great Ones, Uri, Narayana, Wayne, Dejan, Tibor,
Dan, Andrew or Adam could probably tell you the reason and
the fix.
Peter
"I favor the Civil Rights Act of 1964 and it must be
enforced at gunpoint if necessary."
Ronald Reagan
>--Original Message--
>
>Hi,
>One of our developer runs a stored procedure containing
dynamic SQL in
>T-SQL Debugger. She consistently gets error ( see below ):
>SqlDumpExceptionHandler: Process 73 generated fatal
exception c0000005
>EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating
this process.
>If she runs it without debugger, it runs fine. She checks
the code many
>times and can't find anything wrong in the code. We have
no idea what's
>wrong.
>The server is a SQL Server 2000 (SP3) on a Window 2000
with service pack
>4.
>Thank you.
>
>*** Sent via Developersdex http://www.codecomments.com
***
>Don't just participate in USENET...get rewarded for it!
>.
>Thanx for the response.
She ran it on the server and got the same error.
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
Wednesday, March 7, 2012
Run a view and Export results as a CSV file
I need to automate a process for a client and not sure how I can achieve the
following. any help on this would be appreciated.
1. Run a View for the results set
2. Export this data to a csv file.
3. Run a batch job which FTP's the data to an off site server.
Note I have developed the view for my data and know how to implement the FTP
transfer using a batch file/Command. What I don't know is how to export the
results automatically at the end of the view and executing the batch job.
Regards
Jeff
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 13/09/2004
One option is to use DTS to do this.
You can use a data pump task to select from the view. Use a
text destination connection for the destination file and set
this to be a csv file. Then use an execute process task to
execute your batch job or you can use it to execute the
command line FTP to send the files to the FTP site.
-Sue
On Wed, 15 Sep 2004 07:30:03 +1000, "Jeff Williams"
<jeff.williams@.hardsoft.com.au> wrote:
>I need to automate a process for a client and not sure how I can achieve the
>following. any help on this would be appreciated.
>1. Run a View for the results set
>2. Export this data to a csv file.
>3. Run a batch job which FTP's the data to an off site server.
>Note I have developed the view for my data and know how to implement the FTP
>transfer using a batch file/Command. What I don't know is how to export the
>results automatically at the end of the view and executing the batch job.
>Regards
>Jeff
>
>--
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.762 / Virus Database: 510 - Release Date: 13/09/2004
>
following. any help on this would be appreciated.
1. Run a View for the results set
2. Export this data to a csv file.
3. Run a batch job which FTP's the data to an off site server.
Note I have developed the view for my data and know how to implement the FTP
transfer using a batch file/Command. What I don't know is how to export the
results automatically at the end of the view and executing the batch job.
Regards
Jeff
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 13/09/2004
One option is to use DTS to do this.
You can use a data pump task to select from the view. Use a
text destination connection for the destination file and set
this to be a csv file. Then use an execute process task to
execute your batch job or you can use it to execute the
command line FTP to send the files to the FTP site.
-Sue
On Wed, 15 Sep 2004 07:30:03 +1000, "Jeff Williams"
<jeff.williams@.hardsoft.com.au> wrote:
>I need to automate a process for a client and not sure how I can achieve the
>following. any help on this would be appreciated.
>1. Run a View for the results set
>2. Export this data to a csv file.
>3. Run a batch job which FTP's the data to an off site server.
>Note I have developed the view for my data and know how to implement the FTP
>transfer using a batch file/Command. What I don't know is how to export the
>results automatically at the end of the view and executing the batch job.
>Regards
>Jeff
>
>--
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.762 / Virus Database: 510 - Release Date: 13/09/2004
>
Run a view and Export results as a CSV file
I need to automate a process for a client and not sure how I can achieve the
following. any help on this would be appreciated.
1. Run a View for the results set
2. Export this data to a csv file.
3. Run a batch job which FTP's the data to an off site server.
Note I have developed the view for my data and know how to implement the FTP
transfer using a batch file/Command. What I don't know is how to export the
results automatically at the end of the view and executing the batch job.
Regards
Jeff
--
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 13/09/2004One option is to use DTS to do this.
You can use a data pump task to select from the view. Use a
text destination connection for the destination file and set
this to be a csv file. Then use an execute process task to
execute your batch job or you can use it to execute the
command line FTP to send the files to the FTP site.
-Sue
On Wed, 15 Sep 2004 07:30:03 +1000, "Jeff Williams"
<jeff.williams@.hardsoft.com.au> wrote:
>I need to automate a process for a client and not sure how I can achieve the
>following. any help on this would be appreciated.
>1. Run a View for the results set
>2. Export this data to a csv file.
>3. Run a batch job which FTP's the data to an off site server.
>Note I have developed the view for my data and know how to implement the FTP
>transfer using a batch file/Command. What I don't know is how to export the
>results automatically at the end of the view and executing the batch job.
>Regards
>Jeff
>
>--
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.762 / Virus Database: 510 - Release Date: 13/09/2004
>
following. any help on this would be appreciated.
1. Run a View for the results set
2. Export this data to a csv file.
3. Run a batch job which FTP's the data to an off site server.
Note I have developed the view for my data and know how to implement the FTP
transfer using a batch file/Command. What I don't know is how to export the
results automatically at the end of the view and executing the batch job.
Regards
Jeff
--
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 13/09/2004One option is to use DTS to do this.
You can use a data pump task to select from the view. Use a
text destination connection for the destination file and set
this to be a csv file. Then use an execute process task to
execute your batch job or you can use it to execute the
command line FTP to send the files to the FTP site.
-Sue
On Wed, 15 Sep 2004 07:30:03 +1000, "Jeff Williams"
<jeff.williams@.hardsoft.com.au> wrote:
>I need to automate a process for a client and not sure how I can achieve the
>following. any help on this would be appreciated.
>1. Run a View for the results set
>2. Export this data to a csv file.
>3. Run a batch job which FTP's the data to an off site server.
>Note I have developed the view for my data and know how to implement the FTP
>transfer using a batch file/Command. What I don't know is how to export the
>results automatically at the end of the view and executing the batch job.
>Regards
>Jeff
>
>--
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.762 / Virus Database: 510 - Release Date: 13/09/2004
>
run a sql-sript from interface
Dear All,
I'm looking for a VBA-code to run a sql-sript from the Access.adp-interface.
I want to send scripts so my client can add sql-server-objects from the
interface.
Thanks,
Filip"Filips Benoit" <benoit.filips@.pandora.be> wrote in message news:<eEGsb.20778$7o6.640107@.phobos.telenet-ops.be>...
> Dear All,
> I'm looking for a VBA-code to run a sql-sript from the Access.adp-interface.
> I want to send scripts so my client can add sql-server-objects from the
> interface.
> Thanks,
> Filip
There are several options - SQLDMO, SQL commands embedded in your
code, reading in and then executing an external file etc. I suggest
you post this to an Access or VBA newsgroup, as you'll probably get a
better response on which is the best approach.
Simon
Saturday, February 25, 2012
Run a DTS Win32 Process Task hidden
Anyone?
I have a picky client who does not want to see the command window open when a batch file is called from DTS.
Can anyone help me in running it hidden?If you are using a batch file, then the dos window will always open up, at least for a short instant, and there is no way that you can avoid that.
To avoid lookup of commands used then use @.ECHO OFF at the beginning of the batch file.|||That's what I was afrain of.
Originally posted by Satya
If you are using a batch file, then the dos window will always open up, at least for a short instant, and there is no way that you can avoid that.
To avoid lookup of commands used then use @.ECHO OFF at the beginning of the batch file.
I have a picky client who does not want to see the command window open when a batch file is called from DTS.
Can anyone help me in running it hidden?If you are using a batch file, then the dos window will always open up, at least for a short instant, and there is no way that you can avoid that.
To avoid lookup of commands used then use @.ECHO OFF at the beginning of the batch file.|||That's what I was afrain of.
Originally posted by Satya
If you are using a batch file, then the dos window will always open up, at least for a short instant, and there is no way that you can avoid that.
To avoid lookup of commands used then use @.ECHO OFF at the beginning of the batch file.
Rule: Max Number of Lines Per SP
A client believes that "a stored procedure should never have more than about
50 lines of code in it."
No rationalle behind that thought.
When pressed - she stated, "I heard that in a class once a long time ago."
I think this person is an idiot.
Is there or was there ever a time when a such a rule made sense for
technical reasons?
I'm just trying to see how such a belief might possibly make sense.
Thanks.= u r idiot
Message posted via http://www.webservertalk.com|||>> A client believes that "a stored procedure should never have more
than about 50 lines of code in it." No rationalle behind that thought.
<<
Actually, there is both a rationale and a history. Return with me now
to the 1970's when Software Engineering was being born. We would put
bugs into code and give them to people debug, and measure them.
Fifty lines is about one page of hardcopy print out. We found that
code modules that can be seen in toto are measurably easier to maintain
than those that were split across pages or screens. The longer the
module got, the harder the bugs were to find (I cannot remember the
formula, but it was greater than linear). University of Maryland and
SEI had some of the studies, as I recall.
This pattern held across languages, which meant COBOL, FORTRAN, Jovial
and Assembler in those days, then later Pascal and C.
Notice that I said "module", so subroutines, paragraphs or procedures
count as modules depending on your language.
In the case of SQL Server, this was the rule because T-SQL was never
meant to an application language. It is a very simple one-pass
compiler that was used to "fill in the holes" in the early product by
giving you triggers for DRI and other thigns we do declarative today.
.|||Joe,
<<Actually, there is both a rationale and a history>>
YOU have an interesting rationalle. So does everyone else who responded to
my OP, and I agree with all of them to date.
The idiot manager had no rationalle floating around inside her head beyond
"I heard it in a class once." We talked at length... she really had nothing
more than that.
I just wanted to see if I was missing something... apparently not.
Thanks Everyone!
"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1114720755.550812.61610@.g14g2000cwa.googlegroups.com...
> than about 50 lines of code in it." No rationalle behind that thought.
> <<
> Actually, there is both a rationale and a history. Return with me now
> to the 1970's when Software Engineering was being born. We would put
> bugs into code and give them to people debug, and measure them.
> Fifty lines is about one page of hardcopy print out. We found that
> code modules that can be seen in toto are measurably easier to maintain
> than those that were split across pages or screens. The longer the
> module got, the harder the bugs were to find (I cannot remember the
> formula, but it was greater than linear). University of Maryland and
> SEI had some of the studies, as I recall.
> This pattern held across languages, which meant COBOL, FORTRAN, Jovial
> and Assembler in those days, then later Pascal and C.
> Notice that I said "module", so subroutines, paragraphs or procedures
> count as modules depending on your language.
> In the case of SQL Server, this was the rule because T-SQL was never
> meant to an application language. It is a very simple one-pass
> compiler that was used to "fill in the holes" in the early product by
> giving you triggers for DRI and other thigns we do declarative today.
> .
>|||Guadala Harry wrote:
<nothing of importance>
Your choice of words and tone are troublesome...
David G.|||On Thu, 28 Apr 2005 13:03:19 -0700, Guadala Harry wrote:
>A client believes that "a stored procedure should never have more than abou
t
>50 lines of code in it."
>No rationalle behind that thought.
>When pressed - she stated, "I heard that in a class once a long time ago."
>I think this person is an idiot.
>Is there or was there ever a time when a such a rule made sense for
>technical reasons?
>I'm just trying to see how such a belief might possibly make sense.
>Thanks.
>
Hi Guadala,
As Joe indicated, there is some rationale for this rule. But it should
be treated as a rule of thumb. The point is to reduce complexity.
Suppose you have a query like this:
SELECT a.Col1,
b.Col2,
..
e.ColN
FROM Table1 AS a
-- Some useful comments here
INNER JOIN Table2 AS b
ON b.Col8 = a.Col4
INNER JOIN Table3 AS c
ON ...
...
WHERE d.Col18 = 'Asdf'
AND e.Col4 < b.Col8
....
ORDER BY a.Col1,
b.Col2,
...
c.Col8
It's very readable, but probably more than 50 lines. But yoou coould
squeeze it in a lot less lines:
SELECT a.Col1, b.Col2, ..., e.ColN FROM Table1 AS a
INNER JOIN Table2 AS b ON b.Col8 = a.Col4 INNER JOIN Table3 AS c
ON ... WHERE d.Col18 = 'Asdf' AND e.Col4 < b.Col8 ....
ORDER BY a.Col1, b.Col2, ..., c.Col8
But would it be easier to read'
A reverse example: back in my mainframe / Cobol days, creating a report
(or an external interface) required you to move all fields in the
records from the read file to the corresponding field in the records to
be written. Code like this:
OUTREC.FIELD1 = INREC.FIELD1;
OUTREC.FIELD2 = INREC.FIELD2;
...
OUTREC.FIELD138 = INREC.FIELD138;
WRITE FILE (OUTFILE) FROM (OUTREC);
I had a colleague who took the 50-lines rule way too literally - he
would break this routine in three subroutines, and call them after each
other:
CALL FILL_OUTREC_PART1;
CALL FILL_OUTREC_PART2;
CALL FILL_OUTREC_PART3;
WRITE FILE (OUTFILE) FROM (OUTREC);
Senseless overhead, IMO.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||<<Your choice of words and tone are troublesome>>
And ?|||And there are some general rules of respect and courtesy that everyone
should follow when posting. I think everyone understands your frustration -
we've all been there in one form or another (and perhaps even been the
source of frustration at times), but this isn't the forum for venting your
anger especially with insults, deserved or not.
Mike
"Guadala Harry" <GMan@.NoSpam.net> wrote in message
news:O7$gY2ETFHA.2124@.TK2MSFTNGP14.phx.gbl...
> <<Your choice of words and tone are troublesome>>
> And ?
>
50 lines of code in it."
No rationalle behind that thought.
When pressed - she stated, "I heard that in a class once a long time ago."
I think this person is an idiot.
Is there or was there ever a time when a such a rule made sense for
technical reasons?
I'm just trying to see how such a belief might possibly make sense.
Thanks.= u r idiot
Message posted via http://www.webservertalk.com|||>> A client believes that "a stored procedure should never have more
than about 50 lines of code in it." No rationalle behind that thought.
<<
Actually, there is both a rationale and a history. Return with me now
to the 1970's when Software Engineering was being born. We would put
bugs into code and give them to people debug, and measure them.
Fifty lines is about one page of hardcopy print out. We found that
code modules that can be seen in toto are measurably easier to maintain
than those that were split across pages or screens. The longer the
module got, the harder the bugs were to find (I cannot remember the
formula, but it was greater than linear). University of Maryland and
SEI had some of the studies, as I recall.
This pattern held across languages, which meant COBOL, FORTRAN, Jovial
and Assembler in those days, then later Pascal and C.
Notice that I said "module", so subroutines, paragraphs or procedures
count as modules depending on your language.
In the case of SQL Server, this was the rule because T-SQL was never
meant to an application language. It is a very simple one-pass
compiler that was used to "fill in the holes" in the early product by
giving you triggers for DRI and other thigns we do declarative today.
.|||Joe,
<<Actually, there is both a rationale and a history>>
YOU have an interesting rationalle. So does everyone else who responded to
my OP, and I agree with all of them to date.
The idiot manager had no rationalle floating around inside her head beyond
"I heard it in a class once." We talked at length... she really had nothing
more than that.
I just wanted to see if I was missing something... apparently not.
Thanks Everyone!
"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1114720755.550812.61610@.g14g2000cwa.googlegroups.com...
> than about 50 lines of code in it." No rationalle behind that thought.
> <<
> Actually, there is both a rationale and a history. Return with me now
> to the 1970's when Software Engineering was being born. We would put
> bugs into code and give them to people debug, and measure them.
> Fifty lines is about one page of hardcopy print out. We found that
> code modules that can be seen in toto are measurably easier to maintain
> than those that were split across pages or screens. The longer the
> module got, the harder the bugs were to find (I cannot remember the
> formula, but it was greater than linear). University of Maryland and
> SEI had some of the studies, as I recall.
> This pattern held across languages, which meant COBOL, FORTRAN, Jovial
> and Assembler in those days, then later Pascal and C.
> Notice that I said "module", so subroutines, paragraphs or procedures
> count as modules depending on your language.
> In the case of SQL Server, this was the rule because T-SQL was never
> meant to an application language. It is a very simple one-pass
> compiler that was used to "fill in the holes" in the early product by
> giving you triggers for DRI and other thigns we do declarative today.
> .
>|||Guadala Harry wrote:
<nothing of importance>
Your choice of words and tone are troublesome...
David G.|||On Thu, 28 Apr 2005 13:03:19 -0700, Guadala Harry wrote:
>A client believes that "a stored procedure should never have more than abou
t
>50 lines of code in it."
>No rationalle behind that thought.
>When pressed - she stated, "I heard that in a class once a long time ago."
>I think this person is an idiot.
>Is there or was there ever a time when a such a rule made sense for
>technical reasons?
>I'm just trying to see how such a belief might possibly make sense.
>Thanks.
>
Hi Guadala,
As Joe indicated, there is some rationale for this rule. But it should
be treated as a rule of thumb. The point is to reduce complexity.
Suppose you have a query like this:
SELECT a.Col1,
b.Col2,
..
e.ColN
FROM Table1 AS a
-- Some useful comments here
INNER JOIN Table2 AS b
ON b.Col8 = a.Col4
INNER JOIN Table3 AS c
ON ...
...
WHERE d.Col18 = 'Asdf'
AND e.Col4 < b.Col8
....
ORDER BY a.Col1,
b.Col2,
...
c.Col8
It's very readable, but probably more than 50 lines. But yoou coould
squeeze it in a lot less lines:
SELECT a.Col1, b.Col2, ..., e.ColN FROM Table1 AS a
INNER JOIN Table2 AS b ON b.Col8 = a.Col4 INNER JOIN Table3 AS c
ON ... WHERE d.Col18 = 'Asdf' AND e.Col4 < b.Col8 ....
ORDER BY a.Col1, b.Col2, ..., c.Col8
But would it be easier to read'
A reverse example: back in my mainframe / Cobol days, creating a report
(or an external interface) required you to move all fields in the
records from the read file to the corresponding field in the records to
be written. Code like this:
OUTREC.FIELD1 = INREC.FIELD1;
OUTREC.FIELD2 = INREC.FIELD2;
...
OUTREC.FIELD138 = INREC.FIELD138;
WRITE FILE (OUTFILE) FROM (OUTREC);
I had a colleague who took the 50-lines rule way too literally - he
would break this routine in three subroutines, and call them after each
other:
CALL FILL_OUTREC_PART1;
CALL FILL_OUTREC_PART2;
CALL FILL_OUTREC_PART3;
WRITE FILE (OUTFILE) FROM (OUTREC);
Senseless overhead, IMO.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||<<Your choice of words and tone are troublesome>>
And ?|||And there are some general rules of respect and courtesy that everyone
should follow when posting. I think everyone understands your frustration -
we've all been there in one form or another (and perhaps even been the
source of frustration at times), but this isn't the forum for venting your
anger especially with insults, deserved or not.
Mike
"Guadala Harry" <GMan@.NoSpam.net> wrote in message
news:O7$gY2ETFHA.2124@.TK2MSFTNGP14.phx.gbl...
> <<Your choice of words and tone are troublesome>>
> And ?
>
Subscribe to:
Posts (Atom)