>Can someone point me to the standard naming conventioins for tables, fields and stored procedures.

I don't know that there is one.

Beyond the basics of not using keywords or system names, and describing the content as succinctly as possible while maintaining readability, most folks I've talked with recently seem to have foregone naming conventions for tables and fields.

Some still name all stored procedures with an sp_ prefix.

For tables, they pretty much just follow the basics above, but then maybe either force the name to singular or plural (EMPLOYEE or EMPLOYEES), depending on if they see it as describing the table contents or what is contained in a single record.

If you implement a naming convention for fields, a good one should have as few letters as possible in the datatype signifier, which (IMO) is 1. In SQL Server, coming up with a good field naming convention is tricky, then, since there are so many datatypes. i as a prefix -
does that signify int, tinyint, smallint or bigint (new in SQL2K)? Does c mean char or varchar.

So mostly, it's a personal preference or shop preference.
e.g., I tend to follow a functional naming convention, similar to VFP's recommended one - c for character (whatever type), i for integer types, n for non-integer numbers, d for datetime where only the date is significant, t for datetime where the time is also significant, l for whatever is used as a logical field (whether bit, int, numeric, character, etc.), and m for text fields. SQL2K has a sql_variant type, which I like naming with a v