Access to Sql Server Question

have several access databases that are linked to the same backend Access database.* I am in the process of converting all these databbases to SQL server 2000.* I have converted the backend database which contains all the tables to SQL Server.* In an Access database you can link only the tables you want and you can create separate queries in each front end database.* I have a lot of quereis in each database and some have the same name but do different things.
When you have an Access project you get everything from the SQL database - tables, views ……….everything.* I have thought about creating a separate SQL database for each of my applications.* I would have a primary database that contained all the tables, etc and then a separate database that contained only views of the tables in my primary database.* That way I could copy a lot of my quereis directly to each respective SQL database.
Example:
Primary database Table Name:*Authors
Human resources database View Name: Authors with the sql "Select * from pubs.dbo.authors"
If I did it this way then I could copy most of my Access quereis directly to SQL server and have seperate queries and sp's for each application. I would also have my quereis seperated for each application. If I didn't use views then I would have to recreate all my queries which would be a pain because I have a lot of queries based on other queries and would to come up with another naming convention if I wanted to id queries for each application. I have though about just linking the tables and views to a regular Access database but I would prefer to use a project.

Is using views in this way a good idea or a bad idea?

Are there any major drawbacks

That sounds over-complicated. Why not just have one database and have different views for each application that accesses the database. If it's just because you don't want to change your naming convention then I'd say you have a problem with the naming convention. Why not prefix the query with the name of the app?

Add to that, any queries you've done in Access can probably be written to be much more powerful in SQL Server, so you'll probably be better of re-writing most of your queries anyway.

You'd also be able to share any udfs you created too, rather than having to copy them from database to database.
</2 cents>

There were historically a couple of reasons to use views.
1. To hide a complex query join with a simpler interface. It is easier to say SELECT * FROM View than something like SELECT SUM(xxx), AVG(yy) FROM table1, table2..
2. From a security persective, you could hide particular columns of a table from a user.

Until SQL Server 2000, I gave Views a wide berth mostly. Why?? Performance reasons. If I had to select a small subset of data from a View (say data within a certain date range), SQL server would first build the entire View in memory and then tablescan the data for the required date range, instead of using the underlying table data to only select a smaller range of data first and then joining from that. On top of that, it never really used the underlying table indexes for anything. With SQL Server 2000, Microsoft fixed these problems and also allowed Indexed Views.