|
How can I Run SQL Server Agent from VB.NET and get execution status (i.e., Success or Failure). Using VB 6.0 I was able to Declare the connection WithEvents and then use the _ExecuteComplete event of the connection to determine when and how the SQL Server Agent completed the job. The same method doesn't seem to work with VB.NET.
Any help would be appreciated.
Thanks,
Emilio Crespo
ecrespo@pollotropical.com
|
|
|
|
|
I'll try to explain this.
I have a Windows form with a datagrid.
The datagrid binding has been set as MyDataGrid.SetDataBinding(MyDataView, "")
The dataview has also a RowFilter to show only some records.
Now, the problem is that I need to do some calculations whenever something is changed in that table.
For that I use the RowChanged and RowDeleted events.
Now, I have no problems with rows deleted, or rows that are modified, but I do with rows added.
When I add a new row, the RowChanged event does fire, and checking the row property of the event argument I can verify all the data in that row is correct.
However, a that point, all the dataset methods don't seem to "see" that row.
Very strange because the row is being showed on the datagrid.
More strange, if I make any other change, the row becomes "available".
It was driving me crazy because a Select method executed on the datatable would not return the newly added row, but it would if other change was made subsequently.
Just to be sure, in the RowChangedEvent I saved the dataset at that stage using the WriteXml method, then I looked at it and it did not include the new row.
But if I check the count property of the datatable, it has increased by one.
so  it seems that by the time the RowChangedEvent is fired, the row is not available to the dataset methods even though the row IS available to the dataview 
to make things even weirder. I have some code that checks for data integrity in the RowChanged event, if the data is wrong is display a message box and then calls the RejectChanges() method of the row.
That in turn triggers the event again and it exits the procedure because the row is null.
Now if that happens (meaning, if I enter wrong data to trigger the rollback) all subsequent insertions work fine.
even weirder, if I exclude the event handler before calling RejectChanges() (so the RowChanged event won't be trigger by the rollback) the problem persists, meaning new rows are not "seen".
this does not make any sense to me, and only happens if I do my calculations from the RowChanged event. If I add a button and use the button's click event it's fine, so it looks that when the RowChanged event is fired, the new row is in a sort of intermediate state (not the added state but some unforseen state).
This looks like a bug, but I really have no clue what's going on.
I hope this is understandable, it's so weird that I can't make any sense of it.
|
|
|
|
|
|
Hello All,
I'll start with professing my ignorance on this subject! I am calling a stored proc from a sql server 2000 db. The stored proc is as follows:
ALTER Procedure dbo.glpImportFromProcurement
@Account varchar(8000),
@Amount varchar(8000),
@JVType Char(3),
@SourceDocumentString varchar(80),
@SourceDocumentID Int,
@Vendor int
AS
/* Purpose: This imports all pre-encumberance, encumberance, expense, commitments to elite from procurement
Input: @Account - this is the account number(s) (comma seperated) that the transaction hits
@Amount - this is the amount(s) (comma seperated) that match the account number. The accounts must be in double quotes.
@JVType - "pre"(pre-encumberance), "enc"(encumberance), "exp"(expense) When an expense, it will also create the commitment
@SourceDocumentString - This is either the requisition#, PO#, or Invoice#. This is for display purposes for the client to link it to procurement manually
@SourceDocumentID - This is either the Requisition ID, PO ID, or Receipt ID. This is so we know where the transaction came from on a system level
@Vendor - This is the vendor ID for the transaction. We need this to finish the other side of the journal and for the commitment.
Output: Creates appropiate journal and if needed (expense items) a commitment
Return code
Zero = success
< Zero nothing to process
> Zero (failed) and raises
Last Modified:
*/
return 0
(This is just a shell proc that will be filled in later)
So..., when I execute this through my command object it seems to execute fine, but I never get the zero the proc is attempting to return, regardless of what execution method I try. Is there something I'm missing here? I had thought that it was necessary to declare one of the parameters as output in order to return a value.
Thanks,
Ryan
|
|
|
|
|
|
Hello,
I have a question regarding stored procedure desing that provides the
optimal performance. Let's say we have a table Products that consists of
three columns: Name, Status, RegistrationTime. All columns are indexed and
users should be able to lookup data by any of the columns. We have two main
options to design stored procedures for data retrieval:
1. Design separate stored procedures for each search criteria:
LookupProductsByName, LookupProductsByStatus, LookupProductsByTime.
2. Write a generic stored procedure that will fit any search criteria:
CREATE PROCEDURE GetProducts (
@Name varchar(20),
@Status int = NULL,
@FromTime datetime = NULL,
@ToTime datetime = NULL)
AS BEGIN
SELECT
[Name],
[Status],
[RegistrationTime]
FROM [Products]
WHERE [Name]=CASE
WHEN @Name<>NULL THEN @Name
ELSE [Name]
END
AND [Status]=CASE
WHEN @Status<>NULL THEN @Status
ELSE [Status]
END
AND [RegistrationTime]>=CASE
WHEN @FromTimestamp<>NULL THEN @FromTimestamp
ELSE [RegistrationTime]
END
AND [RegistrationTime]<=CASE
WHEN @ToTimestamp<>NULL THEN @ToTimestamp
ELSE [RegistrationTime]
END
ORDER BY [RegistrationTime]
END;
The second option is very attractive, because it is obviously easier to
maintain such code. However, I am a little concerned about performance of
such stored procedure. It is not possible to foresee what index should be
used, index can only be selected each during procedure execution, because
search criteria can include either Name, Status or RegistrationTime. Will it
make this SP inefficient? Or perormance difference in such case is not big
(if any) and we should choose the second option because of its significant
code reduction?
Thanks in advance
Вагиф Абилов
MCP (Visual C++)
Oslo, Norway
Hex is for sissies. Real men use binary. And the most hardcore types use only zeros - uppercase zeros and lowercase zeros.
Tomasz Sowinski
|
|
|
|
|
The 2nd option is not only less efficient than the first, it is less efficient than not using a stored procedure at all. It is also harder to maintain and optimize, because of the complexity.
In my experience, for user-searches, stored procedures are a poor fit. This is because user's demand compex, dynamic searches, and stored procedures are unable to efficiently handle that. In addition, such stored procedures become hellishly long and complex.
my blog
|
|
|
|
|
But you wouldn't defent using SQL statements directly, would you? While I see your point regarding performance, I can't understand reasons for not using stored procedure, or at least user-defined functions. Yes, I agree, for Web searches it is hard to write tens of SPs just to cover all possible cases, but at least UDF makes it possible to pack the code inside the database and not expose SQL directly to clients.
BTW, thanks for the opinion regarding efficiency. Looks like too much of generalisation will harm performance.
Вагиф Абилов
MCP (Visual C++)
Oslo, Norway
Hex is for sissies. Real men use binary. And the most hardcore types use only zeros - uppercase zeros and lowercase zeros.
Tomasz Sowinski
|
|
|
|
|
Well, since you asked...
I would (and do) use SQL statements directly, specially in a web-based applications. Stored procedures offer some benefits, but they also have some drawbacks, such as portability and maintainability. Personally, I almost never use them, but I accept that many people do.
The main benefit of stored procedures is one of security -- you can protect your database against adhoc user queries. In a web application, this benefit does not exist, because the user never has direct access anyway.
In other situations, there are alternatives such as writing a network service component (web service or .net remoting) as an intermediate layer. The business value of such a web service is far more than that of stored procedures.
my blog
|
|
|
|
|
I see your point. Although in our team we try to avoid direct use of SQL. We have multiple tiers, and letting Web developers write SQL directly will make the system uncontrollable.
BTW, I just received a reference to this outstanding article: Dynamic Search Conditions in T-SQL[^]. Exactly on this subject.
Вагиф Абилов
MCP (Visual C++)
Oslo, Norway
Hex is for sissies. Real men use binary. And the most hardcore types use only zeros - uppercase zeros and lowercase zeros.
Tomasz Sowinski
|
|
|
|
|
Steven Campbell wrote:
The main benefit of stored procedures is one of security -- you can protect your database against adhoc user queries. In a web application, this benefit does not exist, because the user never has direct access anyway.
It is always wise to reduce the attack surface of your application. Even if you think that someone cannot get that far in it is still wise to protect all layers as there will always be some bit of code that was writted by a recent graduate, or someone working late on a Friday night, that is not as well thought out that could let someone in.
Stored procedures also have the benefit of being precompiled, and therefor preoptimised. SQL Server 2000 has gone some way to optimising directly called SQL statements by caching the compiled versions so that if the query is run again it already has it in a compiled state and doesn't need to recompile it. But SPs will be precompiled always.
I would suggest the argument that direct SQL is better than Stored Procedures due to portability issues is a false one. Having worked on many database systems over the years I have found that even directly called SQL statements need to be changed when moving from one database system to another, so you are still not guaranteed portability calling SQL directly.
I would also suggest that the argument that directly called SQL statements are easier to maintain is incorrect. If you create stored procedures with a defined interface and the internal structure of the datamodel changes, all you need to do is change the Stored Procedure and everything that calls it will be no wiser to the changes further down. It has all the benefits of an extra layer of abstraction. Calling SQL directly on tables will mean that if the table changes then all the calls to it have to be updated and that can be a lot of work (especially if the database is used by many applications.)
Do you want to know more?
Not getting the response you want from a question asked in an online forum: How to Ask Questions the Smart Way!
|
|
|
|
|
I cannot echo Colin's last point strongly enough. Modularity is A GOOD THING. As Colin suggests, using sprocs frees the rest of your application from needing any knowledge about the underlying table structure. This will matter when you have to make a schema change for V2.0 and spend an eternity tracking down broken select/insert/deletes all over your code. If you use sprocs, all you need to do is assure that they still behave the same, and you're done.
Web apps are actually quite risky, especially if you use query string data to build your sql statements. There are ways to exploit this to get malicious code run on your sql box. Passing the query string data as parameters to a sproc eleviates much of this problem (My experience here is a little limited, so if I am way off, someone please contradict me  )
Bill
|
|
|
|
|
Reducing the attack surface of your application is a good thing, but there are many other things I would recommend before getting to stored procedures:
* do not use sa to login
* encrypt your database connection string
* use parameterized queries
The efficiency/speed argument is bogus, especially considering murphy's law. In the time you'll take to finish the average 6 month project, processors will have improved enough to make the small "precompile" argument meaningless. The same could be said of many techniques for improving performance. Just let it go, and concentrate on creating a well structured application that is easy to maintain. Performance is a concern, but one more likely to be solved by a well placed index.
I'll admit that stored procedures are a useful abstraction for programmers that do not break down their applications into multiple well defined areas of responsibility. However, if you are in the habit of creating multi-tiered, well structured applications:
* SQL is in one place, or sometimes there is no SQL at all (O/R Mapping).
* Code is easily ported to different database platforms (again, the SQL is in one component that can be swapped out or regenerated)
* There is a layer of abstraction between the business code and the database already
I am content to let people use stored procedures if they want to. Most applications have bigger design problems than the decision whether to use stored procedures or not.
my blog
|
|
|
|
|
Steven Campbell wrote:
* do not use sa to login
* encrypt your database connection string
* use parameterized queries
The first and third of these I actually discussed in a blog entry of mine about a week ago so I am well aware of them.
Talking about Murphy's Law: Encrypting a connection string can be more trouble than it is worth. A project I saw recently had encrypted strings, but eventually comments started to appear next to them showing the string in decrypted form to make them easier to work with (it defeats the purpose really - Also, it is better to design a security system that people will not be inclined to break in order to do their everyday jobs). The other problem with encrypted connection strings is that you have to store a key to decrypt them somewhere. Better to use a trusted connection then it doesn't matter whether you know what my connection string is or not as you will still need to know the name and password of a trusted account and access it through a trusted domain.
Steven Campbell wrote:
I'll admit that stored procedures are a useful abstraction for programmers that do not break down their applications into multiple well defined areas of responsibility
Even if the application is broken into well defines areas I still think it is better to use stored procedures because they allow extra boundary checking. There are instances where a value on a record must be cross checked against other date to ensure validity. Constraints on tables can only go so far, for more complex checks SPs are better.
Again, security comes into play here as more security checks can be performed, even if they should have been performed elsewhere you cannot guarantee that another part of the application has not been compromised already.
Do you want to know more?
Not getting the response you want from a question asked in an online forum: How to Ask Questions the Smart Way!
|
|
|
|
|
Steven Campbell wrote:
* do not use sa to login
I strongly agree. That's one of the reasons I like sprocs: I can create a user that has only execute permissions on the sprocs, no direct select, insert, update (much less schema change) permissions.
Steven Campbell wrote:
* encrypt your database connection string
One point to make here: no matter how you encrypt/protect your connection string, your application has to have the ability to decrypt it. So it's inherently vulnerable. It has to be, or your application could not read it. Certainly: it adds another layer of protection I am not sure it's worth the effort.
Just my thoughts...I certainly cannot quantify any of this.
Bill
btw: I have enjoyed reading this thread. Thanks!
|
|
|
|
|
I won't go in to the optimization discussion, but another way to do the same query without the case statements in the where clause is as follows:
CREATE PROCEDURE GetProducts (<br />
@Name varchar(20),<br />
@Status int = NULL,<br />
@FromTime datetime = NULL,<br />
@ToTime datetime = NULL)<br />
AS BEGIN<br />
SELECT<br />
[Name],<br />
[Status],<br />
[RegistrationTime]<br />
FROM [Products]<br />
WHERE [Name]=IsNull(@Name, [Name])<br />
AND [Status]=IsNull(@Status, [Status])<br />
AND [RegistrationTime]>=IsNull(@FromTimestamp, [RegistrationTime])<br />
AND [RegistrationTime]<=IsNull(@ToTimestamp, [RegistrationTime])<br />
ORDER BY [RegistrationTime]<br />
END;
Hope this helps.
Jeremy Oldham
|
|
|
|
|
Thanks. This is of course preferrable syntax. But I ran some tests and figured out that optimization really sucks. So I will go back to specialized stored procedures.
Вагиф Абилов
MCP (Visual C++)
Oslo, Norway
Hex is for sissies. Real men use binary. And the most hardcore types use only zeros - uppercase zeros and lowercase zeros.
Tomasz Sowinski
|
|
|
|
|
Hi All,
Can anybody tell what is the equivalent of "For Update" Statement of oracle in Sybase.
or
It would be very helpfull if u suggest/commemt on this
I 'am using vb.net and syabse. How to handle row locking while updation ?
Thanks in advance.
Vinay
|
|
|
|
|
Does anybody dare to take the this challenge.......
|
|
|
|
|
I used oracleclient to call a storedprocedure, It always display "{"ORA-06550: line 1, column 7:\nPLS-00306: wrong number or types of arguments in call to 'RK001_1'\nORA-06550: line 1, column 7:\nPL/SQL: Statement ignored\n" }" error.
Can give me a sample that it have some input parameters and output parameters(ref cursor)? Or tell me how to solve the question.
Thanks.
|
|
|
|
|
public DataSet GetEntries()
{
//top 5
string ConnectionString = ConfigurationSettings.AppSettings.Get("connString");
SqlConnection SQLConnection = new SqlConnection(ConnectionString);
string SQLView = "CREATE VIEW Content_View AS "
+ "SELECT TOP 10000 [HJ_BLog].* "
+ "FROM [HJ_BLog] "
+ "ORDER BY Date DESC ";
SqlCommand SQLCommandCreateView = new SqlCommand(SQLView, SQLConnection);
SqlDataAdapter DataAdapter = new SqlDataAdapter(SQLCommandCreateView);
DataSet UserSet = new DataSet();
DataAdapter.Fill(UserSet);
SQLCommandCreateView.Connection.Close();
string SQLQueryTop2 = "SELECT TOP 5 [Content_View].* "
+ "FROM [Content_View] ";
SqlCommand SQLCommandTop2 = new SqlCommand(SQLQueryTop2,SQLConnection);
SqlDataAdapter DataAdapterTop2 = new SqlDataAdapter(SQLCommandTop2);
DataSet UserSetTop2 = new DataSet();
DataAdapterTop2.Fill(UserSetTop2);
SQLCommandTop2.Connection.Close();
string SQLDropView = "DROP VIEW Content_View ";
SqlCommand SqlDropView = new SqlCommand(SQLDropView,SQLConnection);
SqlDropView.Connection.Open();
SqlDropView.ExecuteNonQuery();
SqlDropView.Connection.Close();
return UserSetTop2;
}
Pretty much using a view to sort then getting the top 5 from the view then deleting the view. Is there an easier way to do this? I am not sure the preformence hits on creating and droping views. or just a all around easier way to do this.
thanks
any points will be great
|
|
|
|
|
public DataSet GetEntries()
{
string sql = "SELECT TOP 5 * FROM [HJ_BLog] ORDER BY Date DESC";
string ConnectionString = ConfigurationSettings.AppSettings.Get("connString");
SqlConnection conn;
DataSet ds;
SqlCommand cmd;
SqlDataAdapter da;
try
{
conn = new SqlConnection(ConnectionString);
cmd = new SqlCommand(sql, conn);
da = new SqlDataAdapter(cmd);
ds = new DataSet();
da.Fill(ds);
}
catch (Exception ex)
{
}
finally
{
if (da != null) da.Dispose();
if (cmd != null) cmd.Dispose();
if (conn != null) conn.Dispose();
}
return ds;
}
|
|
|
|
|
Thank you, I have no idea what i was thinking when i wrote this.
|
|
|
|
|
Hi Jacob,
I have a couple of fairly phylisophical points to add. Ignore them as you please  .
First off, it's not a really good idea to change database schema from within your code. Creating and deleting view (and table and sprocs, etc) are really design-time processes. Do it before-hand and be done. Why? Well, what happens when user #2 tries to create the view before user #1 drops? You've got an exception to handle... It just get's too messy.
Related to the first point, I am very leary of a program running with a sql user that has sufficient privileges to alter the db schema.
Just my $0.02
Bill
|
|
|
|
|
Is it possible to position to a specific row in a DataTable or DataView? I have a DataGrid that displays either a detail view or a summary view and uses built-in paging. Both sets of data are from the same database table, the summary view is an aggregate (group by) with one less column than the detail view.
When the user changes views, I execute the appropriate stored procedure and re-bind the results to the grid. The problem is I need to re-display the same page of records in the new view. In other words, if the record for company ABC was the first record displayed in the grid in one view, it needs to be the first record in the other view as well. Currently if the user has paged down to page 3 and changes views, they are back on page 1.
Thanks for you help,
Mark
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
