473,696 Members | 1,989 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Using "SELECT * " is a bad practice even when using a VIEW instead of a table?

Using "SELECT * " is a bad practice even
when using a VIEW instead of a table?

I have some stored procedures that are
identical with the difference of one statement
in the WHERE clause. If I create a single View
and specify also in this View the WHERE clause
that is common in these stored procedures, I
will have the new stored procecures changed to
be like:

SELECT * FROM View1
WHERE ID = @ID

Is it a good idea to do this by moving the
common SELECT statement to a View? Will it be
less performant compared to before?
Will this approach cause new problems on
the long run?

I would appreciate your help.

Thank you very much

Please find below a sample code for this.
USE Northwind
GO

if exists (select * from sysobjects where name = 'EMPLOYEE' and xtype = 'U')
drop table EMPLOYEE
GO
CREATE TABLE EMPLOYEE
(
ID INT IDENTITY(1, 1) NOT NULL PRIMARY KEY,
FIRSTNAME VARCHAR(25) NOT NULL,
LASTNAME VARCHAR(25) NOT NULL,
AGE TINYINT NOT NULL,
NOTES VARCHAR(200) NOT NULL,
SPECIALID INT NOT NULL
)
GO
INSERT INTO EMPLOYEE
SELECT 'ABC', 'ABC1', 35, 'Abc', 1 UNION ALL
SELECT 'DEF', 'DEF1', 36, 'Def', 1 UNION ALL
SELECT 'GHI', 'GHI1', 37, 'Ghi', 1 UNION ALL
SELECT 'JKL', 'JKL1', 38, 'Jkl', 1 UNION ALL
SELECT 'MNO', 'MNO1', 39, 'Mno', 1 UNION ALL
SELECT 'PQR', 'PQR1', 40, 'Pqr', 1
GO

if exists (select * from sysobjects where name = 'EMPLOYEEBYID' and xtype =
'P')
drop procedure EMPLOYEEBYID
GO
CREATE PROCEDURE dbo.EMPLOYEEBYI D
@ID INT
AS
SELECT ID, FIRSTNAME, LASTNAME, AGE, NOTES, SPECIALID
FROM EMPLOYEE
WHERE SPECIALID = 1
AND ID = @ID
GO

if exists (select * from sysobjects where name = 'EMPLOYEEBYFIRS TNAME' and
xtype = 'P')
drop procedure EMPLOYEEBYFIRST NAME
GO
CREATE PROCEDURE dbo.EMPLOYEEBYF IRSTNAME
@FIRSTNAME VARCHAR(25)
AS
SELECT ID, FIRSTNAME, LASTNAME, AGE, NOTES, SPECIALID
FROM EMPLOYEE
WHERE SPECIALID = 1
AND FIRSTNAME = @FIRSTNAME
GO

if exists (select * from sysobjects where name = 'EMPLOYEEBYLAST NAME' and
xtype = 'P')
drop procedure EMPLOYEEBYLASTN AME
GO
CREATE PROCEDURE dbo.EMPLOYEEBYL ASTNAME
@LASTNAME VARCHAR(25)
AS
SELECT ID, FIRSTNAME, LASTNAME, AGE, NOTES, SPECIALID
FROM EMPLOYEE
WHERE SPECIALID = 1
AND LASTNAME = @LASTNAME
GO

-- Sample calls to these stored procedures.
EXEC EMPLOYEEBYID 5
GO
EXEC EMPLOYEEBYFIRST NAME 'PQR'
GO
EXEC EMPLOYEEBYLASTN AME 'DEF1'
GO
-- Now if I use a View instead?
if exists (select * from sysobjects where name = 'EMPLOYEESEARCH VIEW' and
xtype = 'V')
drop view EMPLOYEESEARCHV IEW
GO
CREATE VIEW EMPLOYEESEARCHV IEW
AS
SELECT ID, FIRSTNAME, LASTNAME, AGE, NOTES, SPECIALID
FROM EMPLOYEE
WHERE SPECIALID = 1
GO

-- And I create new Stored Procedures
if exists (select * from sysobjects where name = 'EMPLOYEEBYIDNE W' and xtype
= 'P')
drop procedure EMPLOYEEBYIDNEW
GO
CREATE PROCEDURE dbo.EMPLOYEEBYI DNEW
@ID INT
AS
SELECT *
FROM EMPLOYEESEARCHV IEW
WHERE ID = @ID
GO

if exists (select * from sysobjects where name = 'EMPLOYEEBYFIRS TNAMENEW'
and xtype = 'P')
drop procedure EMPLOYEEBYFIRST NAMENEW
GO
CREATE PROCEDURE dbo.EMPLOYEEBYF IRSTNAMENEW
@FIRSTNAME VARCHAR(25)
AS
SELECT *
FROM EMPLOYEESEARCHV IEW
WHERE FIRSTNAME = @FIRSTNAME
GO

if exists (select * from sysobjects where name = 'EMPLOYEEBYLAST NAMENEW' and
xtype = 'P')
drop procedure EMPLOYEEBYLASTN AMENEW
GO
CREATE PROCEDURE dbo.EMPLOYEEBYL ASTNAMENEW
@LASTNAME VARCHAR(25)
AS
SELECT *
FROM EMPLOYEESEARCHV IEW
WHERE LASTNAME = @LASTNAME
GO

-- Sample calls to these stored procedures.
EXEC EMPLOYEEBYIDNEW 5
GO
EXEC EMPLOYEEBYFIRST NAMENEW 'PQR'
GO
EXEC EMPLOYEEBYLASTN AMENEW 'DEF1'
GO
Oct 14 '05 #1
10 5626
Serge - IMO, it's not the * that's bad, it's the lack of a qualifier. I'd
write it as ...

SELECT View1.* FROM View1
WHERE View1.ID = @ID

Now, if you add a join, you don't automatically get all columns from -all-
tables, just the additional columns you specify.

The SELECT in your example could not be moved to a view because views cannot
take parameters, so you can't say "WHERE View1.ID = @ID".

On Thu, 13 Oct 2005 22:30:33 -0400, "serge" <se****@nospam. ehmail.com> wrote:
Using "SELECT * " is a bad practice even
when using a VIEW instead of a table?

I have some stored procedures that are
identical with the difference of one statement
in the WHERE clause. If I create a single View
and specify also in this View the WHERE clause
that is common in these stored procedures, I
will have the new stored procecures changed to
be like:

SELECT * FROM View1
WHERE ID = @ID

Is it a good idea to do this by moving the
common SELECT statement to a View? Will it be
less performant compared to before?
Will this approach cause new problems on
the long run?

I would appreciate your help.

Thank you very much

Please find below a sample code for this.
USE Northwind
GO

if exists (select * from sysobjects where name = 'EMPLOYEE' and xtype = 'U')
drop table EMPLOYEE
GO
CREATE TABLE EMPLOYEE
(
ID INT IDENTITY(1, 1) NOT NULL PRIMARY KEY,
FIRSTNAME VARCHAR(25) NOT NULL,
LASTNAME VARCHAR(25) NOT NULL,
AGE TINYINT NOT NULL,
NOTES VARCHAR(200) NOT NULL,
SPECIALID INT NOT NULL
)
GO
INSERT INTO EMPLOYEE
SELECT 'ABC', 'ABC1', 35, 'Abc', 1 UNION ALL
SELECT 'DEF', 'DEF1', 36, 'Def', 1 UNION ALL
SELECT 'GHI', 'GHI1', 37, 'Ghi', 1 UNION ALL
SELECT 'JKL', 'JKL1', 38, 'Jkl', 1 UNION ALL
SELECT 'MNO', 'MNO1', 39, 'Mno', 1 UNION ALL
SELECT 'PQR', 'PQR1', 40, 'Pqr', 1
GO

if exists (select * from sysobjects where name = 'EMPLOYEEBYID' and xtype =
'P')
drop procedure EMPLOYEEBYID
GO
CREATE PROCEDURE dbo.EMPLOYEEBYI D
@ID INT
AS
SELECT ID, FIRSTNAME, LASTNAME, AGE, NOTES, SPECIALID
FROM EMPLOYEE
WHERE SPECIALID = 1
AND ID = @ID
GO

if exists (select * from sysobjects where name = 'EMPLOYEEBYFIRS TNAME' and
xtype = 'P')
drop procedure EMPLOYEEBYFIRST NAME
GO
CREATE PROCEDURE dbo.EMPLOYEEBYF IRSTNAME
@FIRSTNAME VARCHAR(25)
AS
SELECT ID, FIRSTNAME, LASTNAME, AGE, NOTES, SPECIALID
FROM EMPLOYEE
WHERE SPECIALID = 1
AND FIRSTNAME = @FIRSTNAME
GO

if exists (select * from sysobjects where name = 'EMPLOYEEBYLAST NAME' and
xtype = 'P')
drop procedure EMPLOYEEBYLASTN AME
GO
CREATE PROCEDURE dbo.EMPLOYEEBYL ASTNAME
@LASTNAME VARCHAR(25)
AS
SELECT ID, FIRSTNAME, LASTNAME, AGE, NOTES, SPECIALID
FROM EMPLOYEE
WHERE SPECIALID = 1
AND LASTNAME = @LASTNAME
GO

-- Sample calls to these stored procedures.
EXEC EMPLOYEEBYID 5
GO
EXEC EMPLOYEEBYFIRST NAME 'PQR'
GO
EXEC EMPLOYEEBYLASTN AME 'DEF1'
GO
-- Now if I use a View instead?
if exists (select * from sysobjects where name = 'EMPLOYEESEARCH VIEW' and
xtype = 'V')
drop view EMPLOYEESEARCHV IEW
GO
CREATE VIEW EMPLOYEESEARCHV IEW
AS
SELECT ID, FIRSTNAME, LASTNAME, AGE, NOTES, SPECIALID
FROM EMPLOYEE
WHERE SPECIALID = 1
GO

-- And I create new Stored Procedures
if exists (select * from sysobjects where name = 'EMPLOYEEBYIDNE W' and xtype
= 'P')
drop procedure EMPLOYEEBYIDNEW
GO
CREATE PROCEDURE dbo.EMPLOYEEBYI DNEW
@ID INT
AS
SELECT *
FROM EMPLOYEESEARCHV IEW
WHERE ID = @ID
GO

if exists (select * from sysobjects where name = 'EMPLOYEEBYFIRS TNAMENEW'
and xtype = 'P')
drop procedure EMPLOYEEBYFIRST NAMENEW
GO
CREATE PROCEDURE dbo.EMPLOYEEBYF IRSTNAMENEW
@FIRSTNAME VARCHAR(25)
AS
SELECT *
FROM EMPLOYEESEARCHV IEW
WHERE FIRSTNAME = @FIRSTNAME
GO

if exists (select * from sysobjects where name = 'EMPLOYEEBYLAST NAMENEW' and
xtype = 'P')
drop procedure EMPLOYEEBYLASTN AMENEW
GO
CREATE PROCEDURE dbo.EMPLOYEEBYL ASTNAMENEW
@LASTNAME VARCHAR(25)
AS
SELECT *
FROM EMPLOYEESEARCHV IEW
WHERE LASTNAME = @LASTNAME
GO

-- Sample calls to these stored procedures.
EXEC EMPLOYEEBYIDNEW 5
GO
EXEC EMPLOYEEBYFIRST NAMENEW 'PQR'
GO
EXEC EMPLOYEEBYLASTN AMENEW 'DEF1'
GO


Oct 14 '05 #2
On Thu, 13 Oct 2005 22:30:33 -0400, serge wrote:
Using "SELECT * " is a bad practice even
when using a VIEW instead of a table?
Hi Serge,

Yes. For several reasons.

First, you should never include columns that are not needed in the end
results. Sending extra data to the client wastes network bandwidth.
Using extra columns in the query might preclude the use of an efficient
covering index and force the optimizer to choose a more expensive
execution plan.
Note that this does not apply if you ALWAYS include a column list in
each query that uses the view - unless you index the view, in which case
it will apply anyway.

Second, using SELECT * in a view might cause unexpected errors if the
table is ever modified. Run the following repro to see a proof:

-- Set up table and view
CREATE TABLE Test
(a int NOT NULL PRIMARY KEY,
c numeric(8,2) NOT NULL)
go
CREATE VIEW Test1
AS
SELECT *
FROM Test
go
-- Insert some data
INSERT INTO Test (a, c)
SELECT 1, 3.14
UNION ALL
SELECT 2, 17876.08
-- Show that view looks okay, and that we can do math with column c
SELECT *
FROM Test1
SELECT a, c, c * 2
FROM Test1
-- Add an extra column - note that this one goes at the end
ALTER TABLE Test
ADD b varchar(20) NOT NULL DEFAULT 'x' WITH VALUES
-- We want alphabetic column order, so we temporarily rename the table,
....
EXEC sp_rename 'Test', 'TestOld', 'OBJECT'
-- ... recreate the table in the desired column order, ...
CREATE TABLE Test
(a int NOT NULL PRIMARY KEY,
b varchar(20) NOT NULL DEFAULT 'x',
c numeric(8,2) NOT NULL)
-- ... copy existing data over from old table, ...
INSERT INTO Test (a, b, c)
SELECT a, b, c
FROM TestOld
-- ... and remove the original table.
DROP TABLE TestOld
go
-- Now look what happened to our view!!
SELECT *
FROM Test1
SELECT a, c, c * 2
FROM Test1
go
-- Clean up the garbage
DROP VIEW Test1
DROP TABLE Test
go
(snip)CREATE VIEW EMPLOYEESEARCHV IEW
AS
SELECT ID, FIRSTNAME, LASTNAME, AGE, NOTES, SPECIALID
FROM EMPLOYEE
WHERE SPECIALID = 1
GO


There's very little gain in this example. Note that the actual execution
plan will more than likely be exactly the same. The only advantage you
would have is that part of the logic is included in the view and doesn't
have to be duplicated in all queries. Of course, in this example the
logic is so simple that there's no reason to do this. If your actual
view is quite complex, then you could certainly consider this approach.

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)
Oct 14 '05 #3
serge (se****@nospam. ehmail.com) writes:
Using "SELECT * " is a bad practice even
when using a VIEW instead of a table?


Yes. SELECT * is bad in production code because:

1) The behaviour of the code may change unexpectedly when colunms are
added or dropped.
2) You cannot trace whether a column is actually used or not.
3) Unnecessary data is sent to the client.

There are a few exceptions where SELECT * is permissible:

1) In subqueries with EXISTS/NOT EXISTS of course.
2) From temp tables created in the same procedure.
3) Debug things like IF @debug = 1 SELECT * FROM #tmp.

I would also like to add that you should return columns the client acutally
uses. We are suffering from have several stored procedures where about
every column is included in the result set, and some of these procedures
returns data to clients outside our system. The problem I have, is that I
can't tell whether the column is actually there because of a requirement,
or by routine. This makes it difficult for me, if I need to change or
remove that column.

--
Erland Sommarskog, SQL Server MVP, es****@sommarsk og.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

Oct 14 '05 #4
Thank you all for the answers.

If I may continue adding more information as I am learning
by discussing with some of our developers in our shop.

Our developers are using .NET and I know very little .NET.
I am not even an advanced SQL person to know if what
they want to do is actually good and not bad.

Here's what they are doing. They want to use SPs calling
a single common View and in the view return ALL the columns all the
time. Maybe the biggest table we have has 50 columns maximum.
If I can summarize their points:
1- They are writing our application's SDK and they are standardizing
all the SPs by using "SELECT * from View1 WHERE a = b"
2- They will have our application use these SPs.
3- Only if we encounter performance problems they will deal with
accordingly by adding new SPs. Actually before they even select
that approach they will tackle the performance problem as a DBA
issue and not a developer issue. That is they will expect the DBAs
to deal with the performance problem by making changes on the
tables, indexes etc... before the DBAs get to do anything with the
SPs' code.
4- One of their reasons to use this approach is to guarantee that a
developer will not mess up by adding a new column to the UI and
forget to add it also to x number of SPs.

Now they seem confident that their approach is very good and does
not have any known problems now or down the road.

I am skeptical that the way they're looking at this is as simple as
they're explain it and don't have any complications down the road. I am
not an expert in performance so I couldn't even make my argument
about network traffic that is returning all columns for them to consider
as a problem.

What do you think?

Thank you
Oct 19 '05 #5
serge (se****@nospam. ehmail.com) writes:
Here's what they are doing. They want to use SPs calling
a single common View and in the view return ALL the columns all the
time. Maybe the biggest table we have has 50 columns maximum.
If I were in that shop, it would come to blows, if they were to insist
on this.

We have just too many stored procedures of that kind in our system. They
don't do SELECT *, but they return too many column. And there is a serious
maintenance problem with this. Not all data models are perfect, and every
once in a while you find columns that no longer are in use. Or you suspect
are not in use. Or that may be in use, but you want to change how it is
used. To be able to do this, I need to track down all references to
the column, and if the column is selected from some general procedure,
and into the application - or even worse in some external interface, it's
hard to tell.
4- One of their reasons to use this approach is to guarantee that a
developer will not mess up by adding a new column to the UI and
forget to add it also to x number of SPs.


Yes, in the short run, this saves some time. In 4-5 years timeframe,
they are causing an ever-growing burden of legacy problems.
--
Erland Sommarskog, SQL Server MVP, es****@sommarsk og.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

Oct 19 '05 #6

"serge" <se****@nospam. ehmail.com> wrote in message
news:6C******** ************@we ber.videotron.n et...
Thank you all for the answers.

If I may continue adding more information as I am learning
by discussing with some of our developers in our shop.

Our developers are using .NET and I know very little .NET.
That's ok, sounds like they know even less about proper programming.

You're at least asking the right questions.
I am not even an advanced SQL person to know if what
they want to do is actually good and not bad.

Here's what they are doing. They want to use SPs calling
a single common View and in the view return ALL the columns all the
time.
This is VERY bad design. I'm not even sure where to begin.

Basically it sounds like they're taking a database and throwing out any
semblance of Codd's ideas.

Maybe the biggest table we have has 50 columns maximum.
If I can summarize their points:
1- They are writing our application's SDK and they are standardizing
all the SPs by using "SELECT * from View1 WHERE a = b"
2- They will have our application use these SPs.
3- Only if we encounter performance problems they will deal with
accordingly by adding new SPs. Actually before they even select
that approach they will tackle the performance problem as a DBA
issue and not a developer issue.
And the DBA will start by telling them "DON'T DO THIS!"

But as they're already decided that they're going to ignore the advice of
numerous DBAs, why would they listen then?
That is they will expect the DBAs
to deal with the performance problem by making changes on the
tables, indexes etc... before the DBAs get to do anything with the
SPs' code.
As a DBA I'd break the view. Oops, that means them fixing their code.

4- One of their reasons to use this approach is to guarantee that a
developer will not mess up by adding a new column to the UI and
forget to add it also to x number of SPs.
But, this actually completely negates that goal.

What happens when they add a new column to one of the base tables?

Do they recompile the view? What do they do now when select * returns the
columsn in a different order than before. All their code has to be
rewritten.

Now they seem confident that their approach is very good and does
not have any known problems now or down the road.

I am skeptical that the way they're looking at this is as simple as
they're explain it and don't have any complications down the road. I am
not an expert in performance so I couldn't even make my argument
about network traffic that is returning all columns for them to consider
as a problem.
Network traffic is a definite issue. This won't scale well.

But not only that, they are actually making their maintenace problems far
worse in my opinion.


What do you think?

Thank you

Oct 20 '05 #7
On Thu, 13 Oct 2005 22:30:33 -0400, "serge" <se****@nospam. ehmail.com> wrote:
Using "SELECT * " is a bad practice even
when using a VIEW instead of a table?


....

I've read through this thread and compared it to the practices I've evolved
over time, and I think I have a somewhat different take on it.

1. I find that, in my applications, most tables don't have a very large number
of columns, and most of the columns in a table are likely to be useful in
cases where any of them are.

2. Most stored procedures and views end up getting used from multiple places
in the client code, each with similar, but not identical needs. Most of thems
need most columns, but not exactly the same ones.

3. I add fields to tables relatively often and freely, but remove them
sparingly and with consideration.

4. I (mostly) have unit tests in the client code that will fail if dependent
columns go missing from server query results. Where unit tests are not
present, I sill try to write code with little waste, so most all the code gets
executed in most cases, so breakages will be found early.

5. I almost never write client-side code that will care if extra, unexpected
fields are present in a result.

Under these circumstances, ...

1. I usually find it a good practice to go ahead and select <table>.* for the
most significant table in a select, and select specific fields from other
tables as needed.

2. I don't find that transferring an average of a few extra fields is a
performance burden because the effects of that are completely swamped by other
unavoidable bottlenecks that occur in real-world applications. If there is
one query that is called very often and returns a large number of rows, then
it makes sense to optimize the columns returned for -that- case, not for all
cases just on GP.

3. Limiting the columns to just what's needed in a specific case leads to a
proliferation of views and procedures, mostly the same, but differing in a few
details. That's more server-side objects to maintain when the schema does
change, more obsolete objects being left laying around, and more objects to
paw through to find the one you're looking for.

4. If the issue does exist that a large number of unused fields is present in
a high fraction of queries, that's a strong indication that the schema design
needs some work, not that column output of each query should be better
constrained.
Oct 20 '05 #8
SELECT * in views is buggy even if you require every column:

CREATE TABLE T1 (x INT PRIMARY KEY, y INT NOT NULL)
GO
CREATE VIEW V1 AS SELECT * FROM T1
GO
ALTER TABLE T1 DROP COLUMN y
ALTER TABLE T1 ADD z INT
INSERT INTO T1 VALUES (1,2)
GO
SELECT x,z FROM T1
SELECT x,y FROM V1

Result (SP4):

(1 row(s) affected)

x z
1 2

(1 row(s) affected)

x y
1 2

(1 row(s) affected)

This alone means it isn't an option in my book. Given that it takes
less than two seconds to past the column list into a view definition I
don't see what the excuse is for SELECT *.

--
David Portas
SQL Server MVP
--

Oct 20 '05 #9
On 20 Oct 2005 02:27:37 -0700, "David Portas"
<RE************ *************** *@acm.org> wrote:
SELECT * in views is buggy even if you require every column:

CREATE TABLE T1 (x INT PRIMARY KEY, y INT NOT NULL)
GO
CREATE VIEW V1 AS SELECT * FROM T1
GO
ALTER TABLE T1 DROP COLUMN y
ALTER TABLE T1 ADD z INT
INSERT INTO T1 VALUES (1,2)
GO
SELECT x,z FROM T1
SELECT x,y FROM V1

Result (SP4):

(1 row(s) affected)

x z
1 2

(1 row(s) affected)

x y
1 2

(1 row(s) affected)

This alone means it isn't an option in my book. Given that it takes
less than two seconds to past the column list into a view definition I
don't see what the excuse is for SELECT *.

--
David Portas
SQL Server MVP


I run a program that drops and rebuilds all the stored procedures, views, and
functions. Before it runs, it checks to see if any previously existing
objects have been added or removed, copies the definitions of new objects, and
flags the deleted objects. I had to write this anyway to deal with the
occasional renamed object or column, since that can create a real tangled mess
otherwise.
Oct 20 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

23
5673
by: ian justice | last post by:
Before i post actual code, as i need a speedyish reply. Can i first ask if anyone knows off the top of their head, if there is a likely obvious cause to the following problem. For the moment i've reduced my form request to a simple text string entry, instead of my desired optional parameters. As i have been stuck with a single unfathomable glitch for over a year. Basically, if i enter queries such as ; "select * from table" "select * from...
4
8418
by: Matt | last post by:
In ASP page, there is a "SELECT ALL" button, when user click it, it will select all checkboxes. I am not sure should I use client-side code to do that? the following is my approach but it didnt work. <script language="JavaScript"> function selectAllCheckBox() { //alert(document.addzone.c1.value); document.addzone.c1.value = "on"; } </script>
0
598
by: serge | last post by:
Using "SELECT * " is a bad practice even when using a VIEW instead of a table? I have some stored procedures that are identical with the difference of one statement in the WHERE clause. If I create a single View and specify also in this View the WHERE clause that is common in these stored procedures, I will have the new stored procecures changed to be like:
6
9339
by: GSteven | last post by:
(as formerly posted to microsoft.public.access.forms with no result) I've created a continuous form which is based on a straightforward table (ex - customers - 100 records). On the form there is a checkbox with a control source named "MARK" (boolean) from customer table. I can check and uncheck individual records fine. Then I created 2 command buttons named "Select All" and "Deselect All". The Onclick property of these buttons runs code...
43
2722
by: markryde | last post by:
Hello, I saw in some open source projects a use of "!!" in "C" code; for example: in some header file #define event_pending(v) \ (!!(v)->vcpu_info->evtchn_upcall_pending & \ !(v)->vcpu_info->evtchn_upcall_mask) whereas evtchn_upcall_pending is of type unsigned char (and also evtchn_upcall_mask is of type unsigned char).
1
5470
by: suslikovich | last post by:
Hi all, I am getting this error when insert values from one table to another in the first table the values are varchar (10). In the second they are datetime. The format of the data is mm/dd/yyyy to be easily converted to dates. The conversion in this case is implicit as indicated in SQL Server documentation. Here is my query: INSERT INTO Campaign (CampaignID, Name, DateStart, DateEnd, ParentID, ListID) SELECT ...
1
1426
by: Amil Hanish | last post by:
I use the VS 2005 option "View in browser" to often view my web site. If I have a link in there like: <img src="/graphics/myimage.jpg"> This doesn't work even though the image is really there. I'm sure this has to do with the fact that the page is being served out of the virtual server/port that VS fires up to serve the page. This seems bogus...I can't even see my content? Am I doing something wrong?
0
1314
by: Amil Hanish | last post by:
Earlier I had inquired as to why a normal <a hreftag didn't work when using the VS hosted site using a random local port. The more I think about it, this seems very wrong. Using the random port hosted site, if I have <a href="/mypage.aspx">, this link doesn't seem to work? I've verified this by creating a simple .htm page with a link like this, then do a "View in browser". Clicking the link results in page not found. I guess this is...
0
493
by: Joe Strout | last post by:
Hi Luis, A static variable IS encapsulation. Encapsulation happens at many levels: module, class, instance, and (in languages that support it) method. A static local variable is simply the finest level of encapsulation. (Well, actually you could go one finer in some languages and have block-level static scope.)
0
8597
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9010
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
8880
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
7703
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6515
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5857
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4356
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
1
3033
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
2319
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.