• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3428
  • Last Modified:

Error Number (515) Severity (16) State (3)

Error Number (515) Severity (16) State (3)

"Attempt to insert NULL value into column 'ActualByPort', table '#tmp'; column does not allow nulls. Update fails.Command has been aborted."


We re getting this error on both our development and production boxes, but on production the job continues and finishes.  On development it does not.

Can someone explain this behaivor? Why does it finish in production?
0
leonstryker
Asked:
leonstryker
  • 5
  • 2
  • 2
  • +2
2 Solutions
 
Jim HornMicrosoft SQL Server Developer, Architect, and AuthorCommented:
{wild guess}  
Figure out if you're supposed to allow nulls there
Check the #tmp table declaration in your dev box, and make sure it reflects what you want.
Then see what's populating it.
0
 
leonstrykerAuthor Commented:
The temp table is created by a Select Into method and the data between machines is replicated.
0
 
Joe WoodhousePrincipal ConsultantCommented:
The data may still not be identical - check for defaults that might be overriding NULLs in one system but not in the other? Defaults could be attached to the column directly, or to a user-defined datatype. There may also be triggers, which replication might not be firing.
0
2018 Annual Membership Survey

Here at Experts Exchange, we strive to give members the best experience. Help us improve the site by taking this survey today! (Bonus: Be entered to win a great tech prize for participating!)

 
leonstrykerAuthor Commented:
Thanks Joe, but I found no such differences. It is a bit strange. I fixed the code using the IsNull, so teh issue is no longer there, but its still nagging at me.
0
 
Joe WoodhousePrincipal ConsultantCommented:
Hmm!

Unless there are, say, differences in ASE version (which I assume you've checked), yeah, I'm scratching my head now too!
0
 
knel1234Commented:
Hi,

Do you have different traceon flags set
1) in the run files
2) set after the servers have each started

knel
0
 
leonstrykerAuthor Commented:
knel,

Sorry, but I do not have the ability to check this any longer. Could you expand on your answer?  Have you seen such a thing happening?

Leon
0
 
knel1234Commented:
leon,

I was going down a path similar to Joe.  When an issue occurs, we always look at the version(s) of the server(s).  However, you can see different behavior via the use of different trace flags on the same Sybase versions.  Do you have a copy of the run file from the various environments?  Are you the only dba that works on these systems?  If not, did your partner(s) adjust any traceflag(s)?  Sybase often recommends using various trace flags to adjust/ "fix" certain behavior at least until a patch(next EBF/version) comes out.  I know you mentioned that you dont have the ability to check this any longer.  In the future, you may want to check the OS version, Sybase version, and trace flags.  Of course, these are many things that need to be checked including the particulars of the system (Stored Procs, triggers, etc).

As an example I recently implemented the following, feel free to review Sybase et all for details.

If I wanted to set trace flags for enhanced remote optimization, I have the following options.

I can set it for myself  Dbcc traceon(11216)
I can set it for everyone Dbcc traceon(11216, -1)
I can set it in the run file.  In this case, I believe both -T11216 and  -T11217 would have worked.

11216 - disable enhanced remote optimization (spid)
11217 - disables enhanced remote optimization (global)

You can ignore the specifics of this trace flag.  The point being that trace flags can be set in the run file or on the fly.  In addition, these trace flags will cause different behavior on identical system (ie same solaris and sybase versions).  Therefore, you should verify the trace flag(s) on your systems.  Just one more thing to think about when things on your system go "wrong".

knel
0
 
dave_grCommented:
Easier solution - avoid temp tables and always define your temp tables up front:

create proc do_something
as

create table #blah
(
something_name     varchar(100) not null,
something_date       datetime not null,
something_notes      varchar(255) null
)

insert #blah
(something_name, something_date)
select etc...


This will give you more control and more predictable results.  It will also make debugging easier as you will have described the table definition explicitly rather than inferring it from a select/into.

David
0
 
leonstrykerAuthor Commented:
Yes, except select into is much faster.

Leon
0
 
leonstrykerAuthor Commented:
Thanks for everyone's help. Like I said its out of my hands now, but  I would suspect the answer is check everything.

Leon
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 2
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now