April 1, 2021 at 7:36 am
ohhh.. it does look like I was right after all.
April 1, 2021 at 8:04 am
Any solution from someone?
April 1, 2021 at 8:27 am
basic solutions that any professional should be able to figure out after the issue has been found.
April 5, 2021 at 12:06 pm
Sorry but this solution is not professional in all terms. Components exist within a server for some reason, and the solution is not always to remove them in order to do a job, and maybe cause malfunction to other jobs that are running properly.
Also, I have not authorization to this server and it's not so easy to remove components.
Anyway, I managed to do my job by working through linked server within another SQL server, where the specific problem does not exist, so for now I am OK.
In any case, thank you for your answers.
April 5, 2021 at 8:05 pm
Sorry but this solution is not professional in all terms. Components exist within a server for some reason, and the solution is not always to remove them in order to do a job, and maybe cause malfunction to other jobs that are running properly.
Also, I have not authorization to this server and it's not so easy to remove components.
Anyway, I managed to do my job by working through linked server within another SQL server, where the specific problem does not exist, so for now I am OK.
In any case, thank you for your answers.
Escuse me?
option 1 - if it is software no longer used on the server then yes it can be removed - and would be first thing to do if indeed the software was no longer used.
option 2 - bit trickier in a way - but PATH for the SQL Server user can be set independently of the others so it is a real option so that only SQL Server processes are affected by the change.
option 3 - last resort - but it would work fine and without any need for yet another server to do the work.
so while you may consider them as non options they are perfectly valid even if not ones you like - others exist but a bit more complex and no point in supplying them here.
April 6, 2021 at 7:50 am
I don't intend to argue in any way, I am just trying to find a solution. And yes, I have a second option to do my job, but I would like to figure out why this error appears.
It does not have to do with what I like, but with which solution is the best and it does not affect any other installations. Sybase components are used in many installations and it is not proper to remove them, unless you are pretty sure that they are not used, which I can't tell for sure, cause as I explained I am not the owner of the server.
I have setup my workflow to another server, so I managed to do my job.
April 6, 2021 at 8:31 am
then, and as I said on the options, hardcode the path to the SQL Server BCP and do it that way.
easy and fast - just not portable to other servers if the default install varies (but even for this there are options even if more complex)
the reason is what I said - sybase path is ahead of sql server path executables.
April 6, 2021 at 1:46 pm
Now I'm curious what kind of use case requires Sybase and SQL Server installed on the same system.
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply