Technical Article

Migrating Microsoft Access Applications to SQL Server

Microsoft Access targets individual information workers and small teams that use the Microsoft Office System to track, manage, prioritize, and act upon an increasing volume of business information. The data stored in these databases rarely justifies moving to a more robust platform until the application begins expanding into departmental scenarios. When this happens, it is worthwhile to consider moving the data into a more robust platform for enhanced reliability, scalability, and greater IT control. In most cases, the data can be moved through a process called "upsizing" while the Access application front-end continues to provide information workers with access to critical data. Microsoft has created resources in the following three categories to help manage Access data in your organizations:

External Article

Performance Tuning Tips for Using Microsoft Access

If you are really interested in the fastest performance, don't use Access as a front-end to a SQL Server database. While Access is relatively easy to learn and fast to develop in, its performance if poor when compared to other front-end options. But if you like to develop in Access, or don't have any choice, then the tips on this page will help a little to boost your application's performance.

SQLServerCentral Article

Upsizing the Access Database into the SQL Server

SQL Server and Access are usually linked together as Access used for applications at the beginning of their lifecycle that are later moved to SQL Server when the load gets too high or the data sizes grow. There are often cases where you may also want to use SQL Server as a backend to an Access application. But how do you get your data from Access to SQL Server? Author Dinesh Asanka brings us an overview of the various ways that you can move your Access database to SQL Server.

Technical Article

Slowly Changing Dimensions Are Not Always as Easy as 1, 2, 3

To kick off our first column of the year, we're going to take on a challenging subject that all designers face: how to deal with changing dimensions. Unlike most OLTP systems, a major objective of a data warehouse is to track history. So, accounting for change is one of the analyst's most important responsibilities. A sales force region reassignment is a good example of a business change that may require you to alter the dimensional data warehouse. We'll discuss how to apply the right technique to account for the change historically. Hang on to your hats — this is not an easy topic.

Technical Article

Installing and Configuring SQL Server Reporting Services

In this chapter, we discuss various installation setups you can use to install and configure Reporting Services. For the most part, this process is managed by the Setup.exe installation wizard, so expect to be prompted for a number of configuration options that determine how, where, and whether each segment of the Reporting Services package will be installed. We know that there are a variety of ways to install Reporting Services, so we've tried not only to address the common case, but also provide hints and techniques to be used for some of the more sophisticated installation scenarios. To make this process as painless as possible, we've broken this chapter down into several sections:

Blogs

Crawl, Walk, Run with Agentic Development of Power BI Assets

By

If you’ve been watching AI roll through the data community and thinking, “this seems...

How AgentDBA Diagnoses SQL Server Issues Fast

By

Not every production incident is a database in RECOVERY_PENDING or a corrupted event (like...

Five Ways Redshift Serverless Quietly Eats Your Budget

By

It is Friday, the queries are running, and nobody is watching the bill. That...

Read the latest Blogs

Forums

SQL Art, Part 4: Happy 4th of July — A British DBA's Guide to Celebrating a War We Don't Talk About

By Terry Jago

Comments posted to this topic are about the item SQL Art, Part 4: Happy...

Finding 'bad' characters

By Barcelona10

Hi All I am trying to find 'bad' characters that users might type in....

Extreme DAX: Take your Power BI and Fabric analytics skills to the next level

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Extreme DAX: Take your Power...

Visit the forum

Question of the Day

Changing the Schema

I set up a few users on my SQL Server 2022 instance.

CREATE LOGIN User1 WITH PASSWORD = 'Demo12#1'
CREATE USER User1 FOR LOGIN User1
GO
CREATE LOGIN User2 WITH PASSWORD = 'Demo12#2'
CREATE USER User2 FOR LOGIN User2
GO
CREATE LOGIN User3 WITH PASSWORD = 'Demo12#3'
CREATE USER User3 FOR LOGIN User3
GO
I then created a schema that one of them owned. Under this schema, I added a table with some data.
CREATE SCHEMA MySchema AUTHORIZATION User1
GO
CREATE TABLE Myschema.MyTable(myid INT)
GO
INSERT MySchema.MyTable
(
    myid
)
VALUES
(1), (2), (3)
GO
SELECT * FROM MySchema.MyTable
GO
I granted rights and verified that User2 could access this table.
GRANT SELECT ON Myschema.MyTable TO User2
GO
SETUSER 'USER2'
GO
SELECT * FROM MySchema.MyTable
GO
This worked. Now, I move this schema to a new user.
ALTER AUTHORIZATION ON SCHEMA::Myschema TO User3;
GO
What happens with this code?
SETUSER 'USER2'
GO
SELECT * FROM MySchema.MyTable
GO

See possible answers