Migrate to a SQL Server

[Roy]

Hi,
Bear with me for all these questions which may be basic.
We are planning to move our Backend from Access to SQL Server
enterprise.The front end would remain Access.The SQL Server group in
our organization is allocating servers to us.As a lead developer of my
group who will be going to these initial meetings with the Server
group,I am looking for the right questions to be asked or for which I
need to be prepared.Few questions I could think of are,1) access to all

users across the share and network,2)permissions,3)no access to users
to backend ,4)retrieval of data from back up server in the event of
temporary or permanent inaccessibilty to production servers ,5)
addition of new tables and so on...
If I have missed any important ones,please point those ones.

Thanks,
Roy

[(PeteCresswell)]

Per Roy:

,I am looking for the right questions to be asked or for which I
need to be prepared.Few questions I could think of are,1) access to all

If the DB group starts to get crazy with field names, put up a fight.

I was in one outfit where the DB people insisted on limiting all column names to
20 characters - all uppercase. There was just no reasoning with them.

Aside form the resulting dismal readability in the converted code, it cost them
a lot of my man hours to track down every reference in the app and change it.

Do everything you can to keep the same names that the are used in the current
..MDB back end.
--
PeteCresswell

[Br]

(PeteCresswell) wrote:

Per Roy:

,I am looking for the right questions to be asked or for which I
need to be prepared.Few questions I could think of are,1) access to
all
If the DB group starts to get crazy with field names, put up a fight.

I was in one outfit where the DB people insisted on limiting all
column names to 20 characters - all uppercase. There was just no
reasoning with them.

I wouldn't want ot deal with field name that long either!

All uppercase smacks of "old school" Cobol type days hehe. There are some
good arguments for doing this though, esp when dealing with a system that is
case sensitive.
Aside form the resulting dismal readability
Personally I think 20+ character field names hinder readability. It'd
probably have a small effect on performance too?
in the converted code, it
cost them a lot of my man hours to track down every reference in the
app and change it.
That can be a pain. However there are tools that make it a lot easier (or if
you tempt fate and use Access' auto name correct feature:)
Do everything you can to keep the same names that the are used in the
current .MDB back end.

I can see both points of view. But standards are usually there for a good
reason.
--
regards,

Br@dley