If both the Profiler Trace and the Server Side Trace were identically configured, and you saw different results in two different traces, the only conclusion that I know of is the load (activity) on the server was different between the two traces.
Thanks Brad. I can hardly imagine that being the case, looking at the trace results. Maybe I need to give you an example of what I have configured. Names look odd, but as you will understand I cannot post the actual code here.
In my trace, I have included the following events and columns
With the columns DatabaseName, SPID and Textdata
(it's not a lot, but for the purpose I do not need any other data anyway, so no need to trace that)
I put two filters on the trace, one on DatabaseName, containing the databasename and Textdata with the a string like %partofstoredprocedurename%. This should capture two stored procedures that have this string in the Textdata column: dbo.sprPartofstoredprocedurename and dbo.sprPartofstoredprocedurenamelongversion (no need to tell you what it does, but maybe for other readers - or just in case I'm missing something).
As said before, I do get the correct results running the trace in Profiler GUI, but when exporting the trace to SQL and loading it on the server, it produces quite different results. Not only do I get the desired results, but also different stored procedures such as dbo.sprSomeDifferentCode and dbo.sprUnrelatedCodeforSameDatabase. Also I see lines in my trace with sp_connection_reset, quite a lot actually.
Now I know some tracing might be dropped when the serverload is high, but it wasn't, and the behaviour seems to be consistent. Maybe this extra information will clarify it for you or any other reader on the forum.
Again, thank you for your time.