Schedule Access import to SQLServer - sql-server

SSMA for Access to Console (AccessToSQL)
I created a project with SSMA for Access and successfully imported an Access file to the SQLServernow, I want to automatize the task with SSMA for Access Command Prompt Also I found the documentation to be quite information lacking.
Edit:
With the provided sample XML and some minor tweaks I'm able to migrate the tables, I think my problem is solved.
I think it's because it's trying to migrate the access tabes and queries there is any way to only migrate the tables?
(I should add that migrating only the tables with the SSMA(GUI) works just fine.)
SSMS import Data
I also tried to import the data using the Server Management Studio, but since it's an express edition I'm unable to save the package as described in this process.

Affter fiddling arround for two days I finally managed to make SSMA for Access Command Prompt work by editing the sample script to fit my needs, you can see it here.
Now I'll schedule the task with the Windows built-in scheduler and that should do the trick.

Related

Issues with using AWS-Data-Wrangler in Glue to SQL Server

I've run into an issue with AWS-Data-Wrangler in AWS Glue that I can't seem to find the resolution to. In my searches, I came across this stackoverflow discussion that accurately describes my issue, but the answer isn't helpful because I'm writing the script in GlueStudio. The answer repeats what the source documentation reads about installing unixODBC-devel to install pyodbc, but nothing seems to refer to using the Job parameters function in GlueStudio to install awswrangler and pyodbc together.
To describe what I'm trying to accomplish: we have a bunch of data stored as parquet files that came from our on-premise SQL Server instance. I am trying to take this data and load it into an RDS SQL Server instance so we can run already-existing T-SQL SQL Server scripts against it so we don't have to re-write all of our SQL to match Aurora/Redshift/PostgreSQL/etc. The results would then be stored again in S3 or in another permanent SQL Server instance for use in an application and the RDS instance would be deleted as it is no longer in use. This is to be a first step in migrating our processes into cloud-native technologies and we want to minimize the amount of changes that we would have to make (this would be the ideal end-state of our processes) while also minimizing costs (as permanent SQL Server instances can become quite expensive).
I've tried the following using --additional-python-modules:
pyarrow==2,awswrangler
This results in it missing pyodbc and reporting "ModuleNotFoundError: You need to install pyodbc respectively the AWS Data Wrangler package with the sqlserver extra for using the sqlserver module"
pyarrow==2,awswrangler,pyodbc
This results in awswrangler not being found: "ModuleNotFoundError: No module named 'awswrangler'"
pyodbc,pyarrow==2,awswrangler
This is the same as above.
pyarrow==2,awswrangler[sqlserver]
This is the same as above.
pyarrow==2,awswrangler==2.14.0
This is the same as above
s3://<path>/<to>/<wheel>.whl
I manually built my own wheel file that contained pyarrow, awswrangler, and pyodbc (with all necessary dependencies), but it resulted in the same issue as above.
I've done the above configurations using both Glue 2.0 and 3.0, and one test using Glue 1.0 which took way too long to fail to be viable. At this point I'm stuck and can't figure out how to get this to work out. Without trying to make a connection to SQL Server, awswrangler works fine reading my S3 files and creating dataframes. I've seen mention of using awswranger[sqlserver] but I can't seem to find any actual usage of it in this kind of use-case. Does anyone have any ideas?

How to solve System.OutOfMemoryException in SQL Server 2014

My scenario is my live database is on Azure database name vlproduction and I am using SQL Server 2014 on my local machine, database name testvlproduction. For some reason, my testvlproduction database was deleted.
I want to generate testvlproduction to be the same as vlproduction but I found there is no way to take direct backup of live so I generate script with data but script is too big (300mb) whenever I'm trying to run script on my local it shows
System.OutOfMemoryException
Please tell me, what to do to fix this ? or is there another way to generate database same as live on local
Is there already built any such functionality in SQL Server?
May be this question repeated but still I have no solution for my issue.
Fill free to ask any query.
Thanks
This is a limitation of sql server,This happen because Management Studio is running out of memory, not the SQL Server service.
This is likely caused by the size of the result set that you are returning to Management Studio.
See https://support.microsoft.com/en-in/kb/2874903for more details.
For more sql-server-management-studio-cant-handle-large-files
Since your SSMS runs out of memory you should try it with the a new release. It should be compatible with SQL Server 2014.
If you have some idle time on your production database take a db backup and restore it locally - use Export Data Tier Application and select the proper version where you want to restore. If this is not an option for you I'd suggest to take #mohan111 's suggestion of committing your script in batches.
I believe you have two problems:
System out of memory exception - This usually happens while running big scripts in SSMS. One work around is to run it using command prompt using sqlcmd command (see the link - https://msdn.microsoft.com/en-us/library/ms180944.aspx)
Creating Test Database with the same schema as that of production - You can make use of SSDT tool in Visual Studio. This will help you to create a database project which mimics the production database and you can use the publish functionality to create database where ever required which will have the same schema

Vb app set up with database

Is it possible to make a setup installation of vb.net app including the database.
My database is SQL Server 2008. I've made a vb.net system and i just need to install it but the problem is im not the one who will install it . And so i figured out cause i try it once that i need to install sql server so that it would connct to the database, but the thing is i cant just tell them to nstall the sql server first and instruct to transfer the data and such.
Another thing is that it will be installed in different computer and so when i just use simple sql server, of course the connection of data source should be change and i cant possibly do that since they only want one installer.and what if they change their computer and cant i cant possibly always change the data source of connection.
WHat could be the other way to make a setup where i dont need to install sql server in a computer. A vb app where the setup contain the system and database that can easily be install.I already try installing it and ive already search or an answer and i still cant find one but is still hoping for a clear and detailed answer.

How do I convert Microsoft Access file into SQL Server database?

I want to know how to convert an Access database file into a SQL Server (.mdf file) database?
The MS Access "Upsize Wizard" was discontinued with Access 2012. SQL Server Migration Assistant (SSMA) is now recommended. Reference: https://accessexperts.com/blog/2013/01/30/access-2013-is-here-but-wheres-the-sql-server-upsizing-wizard/
However, as Johnny Bones noted, I found it relatively easy to create a new empty SQL Server (2012) database and then import:
SQL Server Management Studio, R-click on the newly created Database | Tasks | Import Data -> SQL Server Import Wizard
I used "Access Database Engine" instead of "Jet Database Engine" for
no reason other than I GUESSED Jet was older. Mine is a throw-away
project you may want to research the difference.
I 'weeded out' the
Access queries (views) and just imported the tables.
So far it looks
like everything was imported OK.
The simple answer is; you can not "convert" an Access database to a SQL database. You can, however, import the Access database (tables only) into SQL. Remember that SQL is a true database, and, as such, contains no front end or GUI creation mechanisms. You will still need Access (or C# or VB or another front-end builder) to create the interface.
You may already know this, but in SQL Server a Query is called a View, and Modules are called Stored Procedures. You will need to convert your Access queries and modules accordingly if you're planning on having that all reside server-side.
It's actually pretty easy to import Access tables into SQL Server, you would just create a database on a server, right-click on the database name and choose Tasks --> Import Data. There you will choose Microsoft Access as your Data Source. The rest should be pretty self-explanatory.
JonnyBones wrote a good full answer. Other have made suggestions for tools which may work. However, the SSMA (SQL Server Migration Assistant) is likely to be the best option now. (See this youtube video for help with understanding some of the issues to overcome and an explaination of how to use SSMA.
Befre you consider using other tools, which may do more, you should find out why to use them instead of SSMA. Check out the youtube video as a starting point.
Be aware that the MS Access Upsizing wizard was great but is now discontinued, and there was a bit of a gap before MS created a decent version of SSMA, which is when&why these other tools came into existence.
SSMA should do what you need.
There are some access things that do not get moved to SQLServer and some that do.
eg Access triggers do not. Access tables constraints do, Access boolean datatypes so - of sorts - but you need to do some work. The video will explain most issues well.
Harvey
You can try with the Upsize Wizard or copy content of the table from SHOW TABLE DATA and paste to the target table with the same structure as the source.

Extract from Progress Database to SQL Server

I'm looking for the best approach (or a couple of good ones to choose from) for extracting from a Progress database (v10.2b). The eventual target will be SQL Server (v2008). I say "eventual target", because I don't necessarily have to connect directly to Progress from within SQL Server, i.e. I'm not averse to extracting from Progress to a text file, and then importing that into SQL Server.
My research on approaches came up with scenarios that don't match mine;
Migrating an entire Progress DB to SQL Server
Exporting entire tables from Progress to SQL Server
Using Progress-specific tools, something to which I do not have access
I am able to connect to Progress using ODBC, and have written some queries from within Visual Studio (v2010). I've also done a bit of custom programming against the Progress database, building a simple web interface to prove out a few things.
So, my requirement is to use ODBC, and build a routine that runs a specific query on a daily basis daily. The results of this query will then be imported into a SQL Server database. Thanks in advance for your help.
Update
After some additional research, I did find that a Linked Server is what I'm looking for. Some notes for others working with SQL Server Express;
If it's SQL Server Express that you are working with, you may not see a program on your desktop or in the Start Menu for DTS. I found DTSWizard.exe nested in my SQL Server Program Files (for me, C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn), and was able to simply create a shortcut.
Also, because I'm using the SQL Express version of SQL Server, I wasn't able to save the Package I'd created. So, after creating the Package and running it once, I simply re-ran the package, and saved off my SQL for use in teh future.
Bit of a late answer, but in case anyone else was looking to do this...
You can use linked server, but you will find that the performance won't be as good as directly connecting via the ODBC drivers, also the translation of the data types may mean that you cannot access some tables. The linked server might be handy though for exploring the data.
If you use SSIS with the ODBC drivers (you will have to use ADO.NET data sources) then this will perform the most efficiently, and as well you should get more accurate data types (remember that the data types within progress can change dynamically).
If you have to extract a lot of tables, I would look at BIML to help you achieve this. BIML (Business Intelligence Markup Language) can help you create dynamically many SSIS packages on the fly which can be called from a master package. This master package can then be scheduled or run ad-hoc and so can any of the child packages as needed.
Can you connect to the Progress DB using OLE? If so, you could use SQL Server Linked Server to bypass the need for extracting to a file which would then be loaded into SQL Server. Alternately, you could extract to Excel and then import from Excel to SQL Server.

Resources