I assume that the v2016 install selected new ports as the default ports were already taken by a previous install of the trial2016.
I opened only the default ports and took the trial20916 off line. I assumed that my v2016 was listening through those ports and had successful pings to those open ports. So it took me a while to figure it out.
Ike I said in the OP my experience with this stuff is just enough to make me dangerous. My network skills are at about that same level.
I seem to be running OK but I’m having a little difficulty with a stored procedure method.
A few of my apps invoke a stored procedure which then opens a CSV file on a network drive and reads it into a table. For some reason this works sporadically. On one run it will work just fine and then on a second run it will say that the process failed because of permission is not valid.
I have identical databases running on my old serve and this server so I have the luxury of comparing settings. I’ll be hammering this one out this afternoon and hopefully can then move on to tuning things.
Also, if you keep a handle on things like index fragmentation, that will keep your response time good. If you are not familiar with his products, I highly recommend you check out Ola Hallengren’s stuff. It’s free, it’s great and it makes life a lot easier.
For performance tuning in general, IDERA’s stuff is expensive but worth it. If your budget won’t handle IDERA, look atBrent Ozar’s Blitz packages (go to the bottom of the page and click Send Me The Goods). I used them until I got IDERA.
Depending on the specifics of how the SP is configured and is called, the embedded call out to the file system may be using either the SQL Server Service account’s credentials, some specifically configured credentials, or the credentials of the calling application.
Some discrepancy in that chain is probably your issue. Testing everything while running as a box or domain admin can build in a host of these sorts of problems.
It can get gloppier yet if the call to SQL is coming from a web server or app server. Some of those use their own service credentials into SQL Server and some try to pass the end-user caller’s creds along. Which won’t work unless a lot of other crap (can you say “Kerberos”?) is properly configured.
There also might be an issue if the network drive was physically on the old SQL server box and isn’t on the new SQL server box. If so you’ve inadvertently added a layer of box-indirection that needs to be accounted for.
Bottom line: you need to learn exactly which credentials are being used in the call to read the CSV. Both successful calls and failing calls.
Clothahump - I periodically examine tables in my databases and rebuild the indexes if they are fragmented, following up with updating statistics.
Thanks, I’ll take a look at the resources you mentioned. LSLGuy After researching the issue I figured there was a credential problem. You’ve given me some info that may help me run it down.