|
|
Posted by raylopez99 on 07/15/07 11:05
On Jul 15, 2:40 am, David Portas
<REMOVE_BEFORE_REPLYING_dpor...@acm.org> wrote:
> On 15 Jul, 01:05, raylopez99 <raylope...@yahoo.com> wrote:
>
>
> Keys are certainly not irrelevant to your question. They are
> essential. Unfortunately it's hard to be sure what happened based on a
> description of what you did in the GUI. I would advise you to use
> either a decdicated data modelling tool or SQL itself to make these
> sort of changes. I would not recommend VS as a design tool.
Sounds like sound advice. I just upgraded today from the free SQL
Server 2005 Express to the "Developer" version, which has all the
features of the Enterprise version (for a mere $50), except actual
commercial use, which is fine with me since I'm a hobbyiest.
>
> The change you want to make should correspond to something like this:
>
> CREATE TABLE Author (AuthorID INT NOT NULL PRIMARY KEY);
>
> CREATE TABLE Content (AuthorID INT NOT NULL /* PRIMARY KEY NOT
> SPECIFIED! */);
>
> ALTER TABLE Content
> ADD CONSTRAINT fk01 FOREIGN KEY (AuthorID)
> REFERENCES Author (AuthorID);
>
> In other words, AuthorID MUST be a PRIMARY/UNIQUE key in the target
> table being referenced.
You may be onto something. AuthorID is indeed a primary/unique key
in the target table, but since this 'relationship' is being set up in
the early stages of table creation (albeit all tables are saved) then
perhaps "behind the scenes" the VS 2005 IDE is not yet fully cognizant
of this fact. I am firmly convinced it's a bug, since VS2005 does not
create this same error message when working within C++ as a language
(even with the same dB).
Also if you know of a way (format) to "export" dB for debugging
online, as in this group, please let me know.
>
> > I think SQL
> > is a dinosaur language and should be scraped
>
> I agree that SQL is well overdue for replacement. Unfortunately it
> can't happen overnight.
>
> > RDBMS are obsolete
> > in view of cheap memory, faster processors, and managed pointers, but
> > that's another matter.
>
> That's not a coherent line of reasoning at all. An RDBMS implements a
> logical model of data that is independent of the hardware used. If
> processors and memory are faster and cheaper then that makes RDBMS
> faster and cheaper too. What do you propose as an alternative?
>
Pointers indexing, using CAM and a Hash Table, one big, fat, flat
file. THe old way of doing things before IBM researcher E.M. Codd
proposed RDBMS in 1970.
Thanks for your time David Portas. For this particular problem, I
figure that for within C# using VS2005, given using the SQL Server
2005 Express version to create your dB, that the "relationships"
feature is broken. There's a workaround (use C++) and/or I'll see
what happens when I upgrade to the Developer version of SQL Server
2005.
RL
Navigation:
[Reply to this message]
|