Whoever told you to use a three tier architecture clearly has some misunderstanding about the term and passed that misunderstanding to you. Tiers describe a physical separation between the parts of a system, layers describe a logical separation. What you’re after is a layered architecture, you’re already using a two tier one.

A typical three tier application is made up of a presentation tier (web, mobile or desktop applications), a business logic tier and a database/storage tier (SQL Server, MySQL, NOSQL). This is valid for applications that expose their logic to multiple clients through the means of a public API. The StackExchange network can be seen as a multitier architecture.

A multilayer application will be structured, conceptually, the same way as a multitier one, with the important difference that some of the layers (presentation, business logic, data access) can reside within the same physical boundary (tier), such as an assembly or an ASP.NET WebForms application.

The main problem you have in your application is that you don’t have a clear separation between the data access layer, the business logic layer (which can be omitted if you’re merely presenting some data from a database) and the presentation layer, hence the suggestion you received. Your presentation layer should be oblivious to the persistence layer. You are supposed to abstract the data access part of the code behind a class or an interface. This would give you the logical separation between presentation (the webpage) and data access (the class/interface).

Another problem that you may have is that inside the stored procedure you may be performing some business rules which would normally reside within the business logic layer. The opinions on this are divided and the decision on where to place these rules depends on multiple factors.