|
nata2006 wrote: I would prefer a blank TextBox for a null valued field.
Hi nata will why dont you use the try-cach block an let the catch put set the textbox to blank
//sample
try
{
//...your code here
}
catch
{
//your code..plus
txtAnnualIncome.Text = "";
}
I hope this can solve it.
|
|
|
|
|
Thank you cbhkenshin for replying but it doesn't entirely solve my problem.
The thing is I want to create binding between the TextBox's txtAnnualIncome.Text property to the objFirm.AnnualIncome Property on the frmFirm_Load event. In this way, I can avoid initializing the TextBox to the saved value on the Form's startup and setting the value whenever it changes using txtAnnualIncome_Changed() event procedure.
The updating of the objFirm.AnnualIncome is done automaticly whenever the txtAnnualIncome.Text changes without a txtAnnualIncome_Changed() event procedure.
But then, of course, I can't use a try-catch block. I simply don't have where to put it.
I can give up binding all together but it's a very easy and powerfull mechanism and I'd like to use it if there's a work-around to solve the problem of the null valued data fields.
Hope I didn't mix things up too much.
nata2006.
Walk the way. Top down.
nata2005.
|
|
|
|
|
I want to add the names of the staffs, in the dropdownlist, who's login is not yet created.
Eg. consider 2 tables staff, and login
staffs: A,B,C,D,E
login: B,E
the logins are created for B and E so in the dropdownlist it must display A,C,D
i tried the following query but it is not working.
select sname from staff,login where staff.sname!=login.[name]
It leads to duplicated records.....
Please help!!
|
|
|
|
|
You're using some very old join syntax there. The following should work for you:
SELECT sname
FROM staff
LEFT JOIN login
ON staff.sname = login.[name]
WHERE [name] IS NULL How it works: the LEFT JOIN outputs all rows from the left-hand side joined to the right-hand side where the ON condition evaluates to true. If there is no match, it outputs the left-hand side row with NULLs in all the fields from the right-hand side. Because we want the rows which don't have a match, we select only the rows which have NULLs in the right-hand side.
If we wanted only the rows that did match, I'd use an INNER JOIN. That gives only rows where the ON condition evaluates to true.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
select staff.* , login.* from staff,login where staff.sname <> login.name
Proud to be Albanian
|
|
|
|
|
This will also work, if I understand your question correctly (i.e. you want to know what staff members do not have a corresponding record in the login table):
SELECT
s.sname
FROM
staff s
WHERE
s.sname NOT IN (SELECT name FROM login)
or this...
SELECT
s.sname
FROM
staff s
WHERE
NOT EXISTS (SELECT 1 FROM login l WHERE l.name = s.sname)
The most exciting phrase to hear in science, the one that heralds the most discoveries, is not 'Eureka!' ('I found it!') but 'That's funny...’
|
|
|
|
|
From what I understand a foreign key is a unique number which can be used to cross reference items in multiple tables.
How is the foreign key created? Is it created by SQL or does the programmer have to create it and enter it into the table? If this is the case then how can you be sure that the key is unique?
|
|
|
|
|
Let's start with the primary key. The primary key is any combination of values which uniquely identify a particular row in the table. To have the database engine enforce this, you can define a primary key constraint, defining the column or combination of columns which will contain the values which make up the key. The word 'constraint' is often missed off, making the term 'primary key' mean both the collection of columns and the actual values of the row.
If the key is made up from the values of multiple columns, that's often referred to as a compound key. Sometimes compound keys can be unwieldy, so to simplify queries and/or improve performance, a replacement identifier column is defined - often simply a number - which may be referred to as a surrogate key.
A foreign key is basically wherever the values of a primary key for one table appear in another table, hence foreign. By defining a foreign key constraint you can have the database engine enforce the requirement that a matching row (with matching primary key values) exists in the referenced table when inserting or updating data into the table with the constraint. A table can have multiple foreign key constraints. With some database engines, you can also have the database engine automatically delete or update related rows when a row in the referenced table is deleted or updated or, conversely, prevent rows being updated or deleted if those rows are referenced.
See the CREATE TABLE documentation for how to create these constraints if you're creating your tables in SQL. If you're using Enterprise Manager on SQL Server 2000, select 'Relationships' from the context menu in the Design Table window.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Enterprize Manager-->Right click-->Relationships-->
New-->Select Primaty key table from dropdown
-->Select Correspoding Primary key
Select Foreign key table-->Select Corresponding foreign key column
Data base engine it self checks for the foreign key relations
The key can be repeated Primary key is unique key for foeign key table
"I find that the harder I work, the more luck I seem to have."
|
|
|
|
|
Hi
I have a Table T(ID int, FName varchar(50))
What is difference between these commands:
SELECT ID FROM T ORDER BY FName
SELECT ID , FName FROM T ORDER BY FName
???
|
|
|
|
|
The first will return a table consisting of one column, ID's sorted by FName.
The second will return a table consisting of two columns, ID's and FName's, sorted by FName.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
What's faster to execute?
No self-coded ADO.NET transaction:
SqlCommand[] commands = ...;
foreach(SqlCommand command in commands)
{
command.ExecuteNonQuery();
}
One ADO.NET transaction for all of them:
SqlCommand[] commands = ...;
SqlTransaction xaction = connection.BeginTransaction();
foreach(SqlCommand command in commands)
{
command.ExecuteNonQuery();
}
xaction.Commit();
Is there any performance benefit to the second bit, where all the commands are executed within a single transaction? Or would this negatively hurt performance?
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Moral Muscle
The apostle Paul, modernly speaking: Epistles of Paul
Judah Himango
|
|
|
|
|
Judah Himango wrote: Is there any performance benefit to the second bit, where all the commands are executed within a single transaction?
Not more than you'd expect from the equivalent T/SQL-statements. Now, I'm no .NET wizard or anything, but anything that would deviate from the behaviour of T/SQL would be kind of stupid. Especially so since there are SQL-server tailored Sql* classes. Right? 
|
|
|
|
|
Jörgen Sigvardsson wrote: Not more than you'd expect from the equivalent T/SQL-statements.
That's different, isn't it? I've read that a single ADO.NET transaction results in a single handshake between the calling code and SQL, whereas the first code snippet would have many handshakes between the two. Is that accurate or was I reading a programming myth?
|
|
|
|
|
Judah Himango wrote: Is that accurate or was I reading a programming myth?
I'm not sure. I do know that if you deal with OLEDB (COM), you open a connection to the database once. Then you create commands which can operate upon that connection. Furthermore, once you connect to the SQL-server, you create a session, much like the Query Analyzer does for you. That means that each command with a side effect, such as BEGIN TRANSACTION, is visible for all successive commands.
I find the idea of automatic transactions a bit worrysome. Suppose you have to call a stored procedure, which arent transaction neutral. With automatic transactions, life would become hard(er). 
You can always test this by making a stored procedure return @@trancount, and retrieve that through ADO.NET. If it's not zero, and you know you haven't started any transactions manually, then ADO.NET is doing something behind your back...
|
|
|
|
|
By the way, "no manual transaction" - what do you mean by that? All single commands in SQL are atomic, and are transactions in themselves. Either an INSERT completes successfully, or it doesn't.
When dealing with database transactions, you have to specify an isolation level. Depending on what you set, you may get different penalty hits.
|
|
|
|
|
I meant I'm not coding for a transaction specifically. That said, stored procedures (which is what my SqlCommands are calling) that do more than just single actions are not 100% failure or 100% success; that has to be done on manually either by the sproc or the calling code (such as ADO.NET).
My question is really regarding ADO.NET-based trasactions: Is is better to start a transaction from ADO.NET, execute many sprocs, then commit the transaction? Or is it better to just execute a SqlCommand one at at time, letting SQL and ADO.NET handle everything else?
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Moral Muscle
The apostle Paul, modernly speaking: Epistles of Paul
Judah Himango
|
|
|
|
|
The answer depends on what you are trying/needing to accomplish. If it is important that all the steps represented by those SqlCommands succeed, or none succeeed, then wrap them in an enclosing transaction, so that any failure will roll back the parts that succeeded. From a performance viewpoint this will incurr some hit since each operation is logged to the transaction log, and only really executed when the commit is issue (the individual steps might even seem to be a bit faster, but the commit will block longer while the writes actually happen). Enclosing all in a transaction also will cause any page locks that are needed to last for the duration of the transaction, so more will be locked for a longer time. A good rule of thumb is to keep transactions as small as reasonably possible wile insuring database consistency. If some of those SqlCommands could be executed without the others succeeding and not leave the database in an inconsistent state, then leave them out of the transaction.
Transactions aren't so much about performance as they are about database integrity. They aren't free, and should be used judiciously as needed to insure database consistency. Performance is an irrelevant criteria for deciding whether or not to use transactions.
Absolute faith corrupts as absolutely as absolute power
Eric Hoffer
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke
-- modified at 18:24 Friday 10th March, 2006
|
|
|
|
|
Rob Graham wrote: ome of those SqlCommands could
Excellent answer, thanks Rob.
|
|
|
|
|
Another point: you should not mix TSQL transacions (within an sproc) and ADO .Net transactions, as this can cause weird problems. Either do your transactions inside the sproc's, or use ADO .Net transactions, not both.
Absolute faith corrupts as absolutely as absolute power
Eric Hoffer
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke
-- modified at 18:26 Friday 10th March, 2006
|
|
|
|
|
I'm using VB.Net 2003.
I want to connect my client app to a SQL Server over the internet.
How do I send my connection request through the local proxy server?
The setup:
SQL Server --> Firewall -->>>>Internet<<<<-- Proxy Server <-- Client App
The neccesary port forwarding has already been set up.
It's not a HTTP request that I'm looking for. (I think)
/*Im not sure where this post is bet fitted so I put it at the VB.Net forum too*/
|
|
|
|
|
I saw a piece of code in a stored procedure:
DECLATE @ApplicationID uniqueidentifier<br />
SELECT @ApplicationID = NULL
Why did they use SELECT? Wouldn't SET @ApplicationID = NULL be just as good enough?
If I were to declare in my own code the following:
DECLARE @MemberID int
Can I set it to NULL as well?
SELECT @MemberID = NULL<br />
Basically what I would like to do is to get a MemberID based on the input parameter @Username:
-- Variable declaration<br />
DECLARE @MemberID int<br />
SET @MemberID = 0<br />
<br />
-- Get the member ID<br />
SELECT<br />
@MemberID = MemberID_PK<br />
FROM<br />
tblMember<br />
WHERE<br />
MemberUsername = @Username
If no member was found, what would be the value of @MemberID? Would it still be 0?
Regards,
ma se
|
|
|
|
|
ma se wrote: Why did they use SELECT? Wouldn't SET @ApplicationID = NULL be just as good enough?
You could look at it the other way around:
Why use SET? Wouldn't SELECT be good enough?
When you only set one value SELECT and SET are effectively synonyms for the same operation. But, if you want to assign several values at once then SELECT is the way to go because you can do things like this:
DECLARE @a int;
DECLARE @b int;
SELECT @a = 10, @b = 20;
This is faster than doing two separate SET operations, and the more things you need to SET at the same time, the bigger the benefit of using a SELECT.
Also, SET didn't used to be in the language, so the only way to SET values was to use SELECT, so maybe the guy is has been doing databases for many years. Or maybe he just wanted to be consistent accross all of his code and use SELECT everywhere rather than mix SET and SELECT.
ma se wrote: Can I set it to NULL as well?
Yes, but you would have discovered this in the Query Analyzer already, right?
ma se wrote: If no member was found, what would be the value of @MemberID? Would it still be 0?
Yes, it would still be 0, because the SELECT operation returned no rows at all it does not change @MemberID.
ColinMackay.net
Scottish Developers are looking for speakers for user group sessions over the next few months. Do you want to know more?
|
|
|
|
|
Thanks!!
When will your website be up and running? What is the URL again?
|
|
|
|
|
Hi,
I need to extract data from MSDE through ADO.net programmatically.
Can someone help me do this pls.
Thanks.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
