BE tables to SQL Soon. (1 Viewer)

StuartG

Registered User.
Local time
Today, 10:22
Joined
Sep 12, 2018
Messages
125
Morning all.

I currently have two departmental databases and I am currently working with our local IT department to get the DBs into SQL.
The current setup is users have the FE on their Desktops linked to the BE through a network drive.

Would it make sense to keep the two Databases separate when moved to SQL or should I merge the two together and create a main menu users can navigate to depending on departmental needs?

The plus for me by merging would mean I only have one file to maintain instead of two.

Whats everyone's thoughts?

Thanks
Stuart
 

NauticalGent

Ignore List Poster Boy
Local time
Today, 06:22
Joined
Apr 27, 2015
Messages
6,286
or should I merge the two together and create a main menu users can navigate to depending on departmental needs?
You would still be able to do this with one FE. The tables do not have to reside in the same DB to link to them. As far as the convience factor goes, only you can answer that one.

Be sure to look into maintenance plans as well - backups, rebuilding indexes, etc.

Update: Attached is a PDF about MP that I found useful.
 

Attachments

  • Copy of sql-server-maintenance-plans-brad-ebook.zip
    6.3 MB · Views: 294
Last edited:

Pat Hartman

Super Moderator
Staff member
Local time
Today, 06:22
Joined
Feb 19, 2002
Messages
42,981
If the two apps use some of the same tables, combine the BE's so that RI can be properly enforced. If the same users use both FE's, you might combine the FE's BUT, combining the FE's will NOT save any work and in fact will make your maintenance task mush harder because you are making a pathological dependency where none should exist.

It is extremely rare for an Access developer to have responsibility for the production database but you should have some influence over its design and backup requirements.
 

Galaxiom

Super Moderator
Staff member
Local time
Today, 21:22
Joined
Jan 20, 2009
Messages
12,849
Beg them for a login to the server and try to get as many rights as you can for your database. Get what you can and try to get more later.

I recommend you research database roles so you can negotiate with them with some understanding of what you are talking about. It is a complex subject that you won't really get your head around in a hurry but you have to start somewhere.
 

Thales750

Formerly Jsanders
Local time
Today, 06:22
Joined
Dec 20, 2007
Messages
2,061
It is extremely rare for an Access developer to have responsibility for the production database but you should have some influence over its design and backup requirements.
Extremely Rare? If you develop for businesses, most if not all, should be on SQL Server. Access Tables are for Power Users and Micro businesses that write home grown databases. Professional Databases talk to real databases, and MSSQL is the logical choice. Learn it, it's worth it. I have never looked back, and will never deliver another Access BE again.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 06:22
Joined
Feb 19, 2002
Messages
42,981
My development is entirely for businesses and my BE's are usually SQL Server but could be Oracle, DB2 or whatever the client uses for his other apps. And believe it or not, there are still companies that won't allow me to use THEIR SQL Server. Large businesses will balk at even giving me rights to the development server although some will relent once I prove to them I am competent. Production, not in this lifetime. Small businesses are much more inclined to give me access to all the servers. Most will give me access to the production server as well as development but I try not to take it. There is no way I want to be responsible for the company's production data. Medium sized companies usually have full time DBA support. They rarely allow production access but usually allow development access. I am much more of a jack of all trades than most developers but just because I can do something, doesn't mean that I should. I do far more than I should for small companies but I will not ever take on responsibility for production data. My job is schema design and operational advice only.

If you take on responsibility for production data and you are a consultant, you need to have really good Errors and Omissions insurance because if you make a mistake, you could cost a company hundreds of thousands of dollars or even put them out of business. If you're an employee, it doesn't matter. Learn what you can. Get your employer to pay for proper education.
 

AccessBlaster

Registered User.
Local time
Today, 03:22
Joined
May 22, 2010
Messages
5,828
Beg them for a login to the server and try to get as many rights as you can for your database. Get what you can and try to get more later.
That should be made into a "sticky" somewhere on this forum. Without permissions, it's game over.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 06:22
Joined
Feb 19, 2002
Messages
42,981
Without permissions, it's game over.
I guess you have great E&O insurance. You don't need any development permissions to the server to do your job. You just have to build in time to wait for the DBA to do what you tell him to do.
 

AccessBlaster

Registered User.
Local time
Today, 03:22
Joined
May 22, 2010
Messages
5,828
I guess you have great E&O insurance. You don't need any development permissions to the server to do your job. You just have to build in time to wait for the DBA to do what you tell him to do.
Most of us are not hired to do this type of work, we do it to help ourselves or help other employees. If you are hired for a job then you get the permission you need. Most of us are trying to bridge a gap that already exists but we are met with skepticism not only from IT but others. This is the frustrating part of building a database for free.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 06:22
Joined
Feb 19, 2002
Messages
42,981
Working for free changes the rules. But I still would NOT take on responsibility for production data.
 

Galaxiom

Super Moderator
Staff member
Local time
Today, 21:22
Joined
Jan 20, 2009
Messages
12,849
I guess you have great E&O insurance. You don't need any development permissions to the server to do your job. You just have to build in time to wait for the DBA to do what you tell him to do.
I am the dba where I am employed. (And a network admin too.) Small shop with big resources. It is like heaven since they put on a network admin specialist and let me focus on the databases.

The incredibly fine granular permissions on SQL Server means is easy to give a login quite considerable permissions on a single database that won't compromise the rest of the server, plus the ability to read data and execute Stored Procedures from other databases.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 06:22
Joined
Feb 19, 2002
Messages
42,981
I often speak in tongues so it happens regularly;)
 

Users who are viewing this thread

Top Bottom