By the comments you have to understand (I think) that you want to stop using SQL to use LINQ.
In addition to everything Vinícius said, you should not do this if you want the possibility of using several different databases. Perhaps the most noticeable limitation of LINQ To SQL is that it can not work with multiple banks.
If this is your intention you should either create your own mechanism or use some ready one that abstracts the differences between the various banks.
I will not say that I recommend but you should take a look at the Entity Framework , this is ORM which is recommended by Microsoft in such cases. In the Wikipedia page there is a list of other options like NHibernate which still has reasonable use as well.
It's not easy to learn to use them but it should give you the results you expect.
I do not know these products enough to tell you how easy it is to work with stored procedures the way you intend using these technologies.
With EF you can use LINQ but in the LINQ To Entities model.
If you prefer something simpler and you can continue dealing with SQL you can take a look at Dapper . In general I prefer simpler ways. But of course in this case you have to know how to work with the various banks without causing confusion. I particularly find it easier to do this way but most programmers find it easier to leave a framework ready to deal with it.
I reinforce the idea already reported by others that stored procedure is not a good idea for what you want. Much less will bring the benefits you are reporting you will have. I would say it will probably bring the opposite result in some situations.