I want to link an invoice template in Excel to a SQL Server database.
The invoice currently contains only a few very basic fields like user/customer/date/item-id/description/quantity/Total etc.
In future more fields will be required.
What's the easiest way to store all that invoice data in realtime to a SQL Server database when the user presses enter in the invoice?
How many tables will I need to create in SQL Server?
The end users are not tech savvy at all, I need to deploy this solution without any technical requirements from them.
Thank you.
The best way to do this is to create an SSIS package that sucks up the excel spreadsheet and captures the data say once a day. The excel file will need to be in the same location, say a network folder and the structure will also have to be the same, meaning the columns and their names once setup will have to also be the same. Otherwise, it's best to have something like a web front end or a fat32 client (basically build an app in Visual Studio or something) that allows data input directory to the SQL server.
Check out this link to learn about it:
http://knowlton-group.com/using-ssis-to-export-data-to-excel/
Related
Good day :-), I'm a beginner when it comes to asking questions here so please bear with me..
First, let me state the example problem at hand:
Company "A" has 4 branches, each placed in different provinces. Each branch, including the main company has an application that inputs a person's profile and saves it to SQL Server database. All data entered by the branching companies must be submitted to the main branch once in a month. But the main director doesn't want those data to be submitted via cloud, he wants it in a flash drive and one individual from each of those branches must travel to the main company, and submit the flash drive with the data inside.
Because if I just use backup & restore method, they will overwrite everything.
Thus, I have created a dummy database to hold those data. Same table, and each table column has the same data type as the original.
Using VB.NET how does one export the table of a database to a dummy database programmatically?
And once exported, how does one import it to the main company's database?
I'll be grateful if you provide me solutions or if you can point me out to the right direction. Also is my method correct?
You can import/export data from one server to another by using Linked Server.
we can do this also by using sql scripts for using simple select & insert query referring the "Servername.Database.tableName"
Now, if you need to do this in a timely manner, for example for every night you need to import/export the data, what i would suggest is to use Sql Agent. Here you can provide timing to execute the script such as date time and whether it is recursive etc...
with the script of import /export to targeted to specific server.
Ps:
Other approch would be to you use SSIS.
Hope this helps.
Thanks,
Satish
I am building a simple database with about 6-7 tables. I will be setting a schedule to do a clean import from a .txt file.
I want to take this data and create a report, like I would do in an excel spreadsheet, convert it to a pdf and post it to our company intranet for those interested to access it.
I'm trying to think of the best way to build my report. Would I just use an excel spreadsheet with a direct connection to the database? Would I create some sort of console application (c/c#/vb/vb.net) that would query the db, generate the report in an excel file, convert to pdf and save?
I'm quite comfortable in these different languages, just not as experienced in the reporting services (although I do have a lot of experience working with EXCEL and VBA Macros) but I want to get into it (SSRS) and get familiar with it as I will be doing a lot of projects like this in the future. This is seems like an easy one to get my hands dirty with and learn and build off of.
Any insight or suggestions would be greatly appreciated.
Thanks so much!
My suggestion:
Create desired SQL queries to retrieve the data in desired form
Link these queries to your Excel sheet, perhaps directly in form of pivot tables for aggregation of results
Using VBA, you can easily create PDF from the data at the click of a button
The initial design will be time intensive, but after that, everything is automated and one just needs to press the button that creates the PDF.
How to link Access queries to your Excel file:
Data --> Get external Data
You can easily refresh all data whenever you open the Excelsheet by using the code below in the On Open event of the workbook:
ThisWorkbook.RefreshAll
If you need further clarification, do not hesitate to ask
If your end goal is to create a PDF that will be out on your intranet then I would create the report in SSRS. Then you can schedule it to run and output a PDF to your network location.
I've had good experiences using a pivot table in Excel which is a connected table to your SQL database.
In the connection parameters in Excel there is a field where you can define your SQL query, whether it be to call a stored procedure or just a simple SELECT statement.
The main reason I prefer a pivot table SQL connection rather than a normal table connection is because if you have a chart that references the connected table, the chart formatting will be reset when you refresh your connection (if you need to updated your report).
If I use a chart that references a pivot table (or a pivot chart) then the formatting is retained.
I'm building a huge inventory and sales management program on top of Dynamics CRM 2011. I've got a lot done but I'm kinda stuck on one part:
Images are stored in the database encoded as base64 with a MimeType column. I'm wondering how I might extract those images programmatically on a schedule to be sent as part of a data transfer to synchronize another DB.
I have a SQL Server Agent job that exports a view I created. I'm thinking about writing a program that will take that resultant CSV and use it to get a list of products we need to pull images for, and then it queries the DB and saves the files as say productserial-picnum.ext
Is that the best way to do that? Is there an easier way to pull the images out of the DB and into files?
I'm hoping it will be able to only export images that have changed since say a Last Modified column or something.
I don't know C# at all, VB, PHP and JavaScript enough to do some damage though..
you should be able to achieve this in TSQL itself
OPEN cursor with qualifying records (where now>lastmodified etc)
For Each Record
Select Binary Data into "#BinaryData
Convert "#BinaryData to #VarcharData (Something like below will work)
SET #VarcharData = CAST(N'' AS XML).value('xs:base64Binary(xs:hexBinary(sql:variable("#BinaryData")))', 'VARCHAR(MAX)')
Write #VarcharData to file (on server or a network drive if the agent is configured to write out)
Close File
Next Record
I am trying to reconcile data from a website and a database programmatically. Right now my process is manual. I download data from the website, download data from my database, and reconcile using an Excel vlookup. Within Excel, I am only reconciling 1 date for many items.
I'd like to programmatically reconcile the data for multiple dates and multiple items. The problem is that I have to download the data from the website manually. I have heard of people doing "outer joins" and "table joins" but I do not know where to begin. Is this something that I code in VBA or notepad?
Generally I do this by bulk inserting the website data into a staging table and then write select statments to join that table to my data in the database. You may need to do clean up first to be able to match the records if they are stored differently.
Python is a scripting language. http://www.python.org
There are tools to allow you to read Excel spreadsheets. For example:
http://michaelangela.wordpress.com/2008/07/06/python-excel-file-reader/
You can also use Python to talk to your database server.
http://pymssql.sourceforge.net/
http://www.oracle.com/technology/pub/articles/devlin-python-oracle.html
http://sourceforge.net/projects/pydb2/
Probably the easiest way to automate this is to save the excel files you get to disk, and use Python to read them, comparing that data with what is in your database.
This will not be a trivial project, but it is very flexible and straight forward. Trying to do it all in SQL will be, IMHO, a recipe for frustration, especially if you are new to SQL.
Alternatively:
You could also do this by using VBA to read in your excel files and generate SQL INSERT statements that are compatible with your DB schema. Then use SQL to compare them.
I need to upsize a split Access database, i.e., one that's currently split between tow mdb files, a front-end and back-end. I see many webpages that in essence say, "run the Upsizing Wizard." My first, very basic question:
Should I be running this wizard in my front-end mdb or my back-end mdb?
I assume I don't want to link main mdb -> backend mdb -> sql server. Should I run the wizard on the backend mdb, and then in the frontend mdb change the linked tables to point to sql server rather than to the backend mdb? If so, how is this done? When I right-click and go into the Linked Table Manager for a table in the frontend (linked to the backend md), it only seems to let me choose a new mdb file.
I would agree with your first guess: you will want to run the wizard on the back-end mdb.
Once that's in SQL Server, also as you guessed, you'll want to link the front end to work with the SQL Server data. One way to do this is to set up an ODBC data source for your new SQL Server database and select that in the Linked Table Manager.
Open the Data Sources (ODBC) shortcut: in XP Pro, this is in the Control Panel under Administrative Tools. (If you don't see it, you probably don't have permission to create a data source, so you'll have to work with your network people to do this.) This will open the ODBC Administrator.
On the File DSN tab, click Add.... You'll see a list of available drivers. Select SQL Server and click Next. (If the front end is only being used on your machine, you can create a System DSN instead.)
Find a common location and name your data source.
Click Next and Finish. This will set up the first part of the data source, and will open the SQL Server data source wizard.
Name the data source and select the server on which you've put the upsized back-end database.
Change the rest of the settings as needed (you may not need to change much, but the scope of those changes may require a second question) and click through to Finish.
Once you have the data source set up, then Get External Data should give you the option to select it as your source. (In 2007, you can get there from the External Data ribbon. ODBC data sources are available under More.)
To expand a little further based on Matt's follow-up questions:
How you do it is a design choice. I recommend upsizing the back-end mdb because that would allow you to keep whatever forms and such you had in Access; I think it's less of a transition if your data is in SQL Server.
Before you upsized, your tables were linked to the back-end database, and the Linked Table Manager showed the links. After you set up the ODBC data source and linked those tables, it'll show that link. You'll view the links in two different ways because they're actually different types of links (Access vs. ODBC), even though the links may look the same in your front-end mdb.
Personally I have found that the upsizing wizard does a very bad job of determining correct datatypes. I would create the tables myself in SQL server using the datatypes I need, then move the data to the existing tables from Access. other wise you will be stuck with text data when you could use varchar or float when you really need decimal.
Once the data has been moved then I would delete the Access tables and link to the SQL Server tables.
Do not do anything without having a backup copy of the database first.
As a matter of standard paranoia, I would just make a backup copy of the existing files and run the Upsizing Wizard on the front end. If anything undesirable happens, just revert the changes by overwriting with the backup copy.
Update the front end, and it will import the back end tables before it upsizes. I did this a week ago with a successful result.
However, any queries that use -1 instead of Yes will fail. Any full table deletes on tables without a primary key will fail, and you will get different behaviour from that than you will by merely using a pass-through SQL query to truncate table. The trunc will delete all rows, the Access version may leave a blank.
Also you'll need to include dbSeeChanges anywhere you have a recordset opening on a table with an autonumber column data type. SQL changes these to Identity data types, then gripes before you try to open the table. Good luck.
Do it all in the front end
You can simply export the tables to SQL Server.
You can then delete the linked tables you have in your frontend.
Then link the connection to SQL Server
Check:
when you open tables you get records
all your queries run
compile your code
You will also have to consider how you are releasing the front end. If you are using a dsn file you will need to provide that to each user.
You will need to determine how the end user accesses SQL Server. Are you using a single login with the username and password stored in the connection?
You could also split your backend DB into multiple Access DB and link them in the frontend.