It depends on your skill set.  How well do you know SQL Server?  Are you
happy to do the database design, and the admin (manage logins, backups,
maintenance, etc)?  Are you happy writing stored procedures in Transact SQL
or are you more familiar with Access queries?
What about Access?  Have you ever built an application using the adp format?
If not, how long have you got to learn this technology and then build.
With my skills and experience, I would choose an mdb file on each pc, SQL
Server database as the datasource.  The mdb format allows me to use a number
of different ways to access the data: linked odbc tables and also DAO and
ADO coding.  Perhaps someone will suggest adp with bound forms but I doubt
whether they would suggest adp and unbound forms - what is the point?  I
would avoid adps all together, but this topic has been thrashed out so many
times, I'm not sure if there is much to say which is not publicly available
on the web.

Brian's reply covers most of what I would have offered.  I would ask,
though, how large your 300.000 rows are?  Are you adding 300.000 bytes per
year or 300.000.000?

Were it me, with SQL Server available, I'd probably put the data in SQL
Server and use Access (DAO/ODBC) as a front-end on each PC.

4) a standard MDB front end, and linked tables to sql server.

4 is a good choice if you have an existing application, and want to migrate
it to sql server. A ADP is a good choice if you are starting from day 1 with
sql server. Your existing mdb file with code will not convert to a ADP, and
this is especially so if you used lots of dao code....you will have to
re-write it.

So, often, option #4 is preferred for *existing* applications. You simply
use odbc tables, and thus can salvage about 90% of your code...