Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Management wants to avoid Identity columns

2 views
Skip to first unread message

wi...@maccnet.com

unread,
Feb 23, 1998, 3:00:00 AM2/23/98
to

Help! My development team has spent the past 2 years writing an accounting
package for MSSQL. Now management wants the same application to run on the
AS400 using DB2. DB2 doesn't have an auto increment feature like MSSQL's
Identity so Triggers or an 'Auto Increment' Table will be used to get the
same effect. Sounds sane so far but here's the kicker. They want to stop
using Identities on the MSSQL side so that both the MSSQL version and the DB2
version are the same. This seems very wrong to me. I've found Identities to
be very useful. Didn't Microsoft add them for a reason? The problem is I
don't have the background necessary to argue my case. I'd bet that using
Identities is faster than manually generating the numbers but I can't really
say for sure because I've never manually generated numbers. Could someone
who knows comment on the decision to avoid Identities on MSSQL? How using
Triggers instead will affect the speed of the application and things like
that. Thanks in advance Will Judson wi...@maccnet.com

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading

Kent Milligan

unread,
Feb 24, 1998, 3:00:00 AM2/24/98
to

I think that you have hit on the key point about the
Identity fields is that they impact portability.

The AS/400 Partners In Development site does provide
a sample trigger program for implementing the auto
increment feature. Just look around at the following URL:
http://www.softmall.ibm.com/as400/client

--
Kent Milligan, DB2/400 Solutions Team
AS/400 Partners In Development
km...@us.ibm.com
GO HAWKEYES!!
(opinions stated are not necessarily those of my employer)

Randy Charles Morin

unread,
Feb 25, 1998, 3:00:00 AM2/25/98
to

Identities and triggers and many other proprietary features of various
dbms' make converting your code from one dbms to another a problem. I've
found that you can accomplish anything using very limited SQL. I agree
with your management, but I would go further. Not only would I stop using
identity in MSSQL, I wouldn't use triggers and auto-increment either. I
would stick with basic SQL.
During one project, I used only simple SQL when we were targeting Ms-SQL
Server. When management decided they needed our 300+ SQL statements
converted to Ms-Access, only 200 hours later we had a production version in
Ms-Access. And by using the same code for both Ms-Access and Ms-Sql, we
had to do half the work when we discovered bugs in the SQL. Keep it
simple.
--
Randy Charles Morin - mailto:middl...@ica.net
MiddleWorld SoftWare - http://web2.ica.net/middleworld
--------------------------------------------------
He went out of his way to be good.

wi...@maccnet.com wrote in article <6csnl5$p9g$1...@nnrp2.dejanews.com>...

0 new messages