By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,806 Members | 1,841 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,806 IT Pros & Developers. It's quick & easy.

How add rows to table in Microsoft SQL 2008 Server

P: n/a
Hi!
Simple questio - how to add rows to table in Microsoft SQL 2008
Server.
I don't mean by executing query (INSERT INTO...), but by clicking on
table or something - not by writing query manual.
When I'm clicking RMB on table I can't see nothing like "open",
"add"... Insead of these I have "new table...", "design", etc.
Nov 14 '08 #1
Share this Question
Share on Google+
9 Replies


P: n/a
krzys wrote:
Hi!
Simple questio - how to add rows to table in Microsoft SQL 2008
Server.
I don't mean by executing query (INSERT INTO...), but by clicking on
table or something - not by writing query manual.
When I'm clicking RMB on table I can't see nothing like "open",
"add"... Insead of these I have "new table...", "design", etc.
SQL is not Access. You probably want to create an Access file with
linked tables pointing to SQL, or the equivalent with Access replaced
by (insert favorite front-end tool here).
Nov 14 '08 #2

P: n/a
On Nov 14, 4:31 pm, Ed Murphy <emurph...@socal.rr.comwrote:
>
SQL is not Access. You probably want to create an Access file with
linked tables pointing to SQL, or the equivalent with Access replaced
by (insert favorite front-end tool here).
What, you're not going to recommend he look at Dataphor! :)

www.beyondsql.blogspot.com
Nov 14 '08 #3

P: n/a
As far as I can remember in SQL Server 2005 by clicking RMB on table
there was option "open"...
Nov 15 '08 #4

P: n/a
On Fri, 14 Nov 2008 23:03:14 -0800 (PST), krzys wrote:
>As far as I can remember in SQL Server 2005 by clicking RMB on table
there was option "open"...
Hi krzys,

That has been replaced by "Edit top 200 rows", and as far as I know can
still be used to enter new rows.

However, I suggest that you don't use this option, nor the "edit" option
in SQL 2005. There are various known issues with both methods of
entering data.

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
Nov 15 '08 #5

P: n/a
On 15 Lis, 22:53, Hugo Kornelis <h...@perFact.REMOVETHIS.info.INVALID>
wrote:
On Fri, 14 Nov 2008 23:03:14 -0800 (PST), krzys wrote:
As far as I can remember in SQL Server 2005 by clicking RMB on table
there was option "open"...

Hi krzys,

That has been replaced by "Edit top 200 rows", and as far as I know can
still be used to enter new rows.

However, I suggest that you don't use this option, nor the "edit" option
in SQL 2005. There are various known issues with both methods of
entering data.

--
Hugo Kornelis, SQL Server MVP
My SQL Server blog:http://sqlblog.com/blogs/hugo_kornelis
Great answer - thansk a lot!
Nov 16 '08 #6

P: n/a
steve wrote:
On Nov 14, 4:31 pm, Ed Murphy <emurph...@socal.rr.comwrote:
>SQL is not Access. You probably want to create an Access file with
linked tables pointing to SQL, or the equivalent with Access replaced
by (insert favorite front-end tool here).

What, you're not going to recommend he look at Dataphor! :)

www.beyondsql.blogspot.com
No, at least not yet. Dataphor may be a useful platform for new
project development, but (as I've said many times before) for existing
projects - of which there are many - the cost of switchover would
usually hugely outweigh any potential benefits.

I'll take this opportunity to quote something I wrote back on
October 22 - you haven't replied yet, would you like to do so now?
As previously discussed, I agree that table-type variables would be
useful in other situations, though I still think you're shooting
yourself in the foot by constantly pointing to an instance (Dataphor)
that would incur a huge switchover cost for existing projects. SQL
Server 2008 has table-valued parameters, albeit limited to read-only
input parameters; within that limit, do you approve of them?
Nov 17 '08 #7

P: n/a
On Nov 16, 8:26*pm, Ed Murphy <emurph...@socal.rr.comwrote:
[snipe]

I'll take this opportunity to quote something I wrote back on
October 22 - you haven't replied yet, would you like to do so now?
As previously discussed, I agree that table-type variables would be
useful in other situations, though I still think you're shooting
yourself in the foot by constantly pointing to an instance (Dataphor)
that would incur a huge switchover cost for existing projects. *SQL
Server 2008 has table-valued parameters, albeit limited to read-only
input parameters; within that limit, do you approve of them?
Hello Ed,

To be charitable I suppose some will make use of it. I don' see that
it can do any harm except psychologically. It seems to me that I can
only pass the Orders table in the Northwind db if it's something else
(I assume their using the temp db). Then obviously I can't pass Orders
itself:) It reminds of the riddle, when is a door not a door? When
it's ajar:) Most users probably can't appreciate where I coming from
because they do not know what it 'really' means to pass a table as a
parameter (as I've shown in many articles). Perhaps I'll further
dissect the craziness of the idea of a TVF in its own special article.
In the meantime I suspect there are much bigger fish to fry :)

best,
steve
www.beyondsql.blogspot.com
Nov 17 '08 #8

P: n/a
steve wrote:
To be charitable I suppose some will make use of it. I don' see that
it can do any harm except psychologically. It seems to me that I can
only pass the Orders table in the Northwind db if it's something else
(I assume their using the temp db). Then obviously I can't pass Orders
itself:)
I agree that SQL 2008 doesn't cover all of your suggestions - I was
just pointing out that it seems to cover at least some of them.
Most users probably can't appreciate where I coming from
because they do not know what it 'really' means to pass a table as a
parameter (as I've shown in many articles).
That's probably true in many cases, but here is (I suspect) why they
aren't learning from you in particular:

1) Dataphor is a niche product. Existing projects, of which there are
many, would suffer major switchover costs. Even new projects would
require the developer to spend some time learning Dataphor's
interface for app development. There are cases where these costs
would be worth it, but by failing to address these limits, you come
off sounding like an impractical ivory-tower theorist and/or fringe
religious cultist.

This would be greatly mitigated if you translated your ideas into
hypothetical extensions of SQL, and lobbied to have such extensions
added to the industry standard. I've even given examples of this
in the past, but you didn't seem to see any significant value in
it; even SQL 2008's actual (albeit incomplete) progress on this
front was met with no more excitement than "meh, might help a bit".

2) Grammar can't just be swept under the rug with "my style is more
important". First, technical subjects require clear communication,
full stop. Second, your style is far from unique; even in artistic
fields, only a few of us can be a cummings or Silverstein.
Nov 18 '08 #9

P: n/a
On Nov 18, 1:39*pm, Ed Murphy <emurph...@socal.rr.comwrote:
>...here is (I suspect) why they aren't learning from you in particular:
1) Dataphor is a niche product.
I was hoping it would be seen as a Nietzschean type product:) Note
that many
products are nichey along the way to becoming widely used. MySql was
once a niche product (a label used pejoratively by MS and other
vendors). Today it's advocates would argue it's quite the mainscream.
Existing projects, of which there are many, would suffer major switchover
Nov 20 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.