So I was making a new connection to an MS SQL server using the wizard and realized I don't know REALLY why it has me save these ODC connection files.
So, what are they and why does Excel create them?
Further, what happens to these files once when I change the connection from just selecting a table, to a custom SQL statement I have created?
Does anything change in these ODC files? I know sometimes it complains that if I make a change it will no longer match what is stored in the file.
edit:
I decided to look into one of my ODC files and it is HTML combined with some XML tags and then even a little JavaScript. So that is interesting. Still not sure how Excel uses these files instead of just storing that data itself. I guess to provide connections to multiple workbooks.
I think the idea is that you can share these files. You could put an odc on a network share or on SharePoint, have multiple workbooks use the odc file, and if any updates were necessary (like the database moved), then you only have to change it in on place.
Also, if you double click the odc file, it will create a new workbook with that connection and a table. I guess that could be a lean way of sending a workbook that consists of only an external data table to someone with access to the same connection. I haven't used that myself, but, you know, theoretically...
Why did they choose this as the default? I don't know. I wouldn't have. I would have chosen to have the data stored in Excel, but still have the ability to Export an odc for those that want to go that route. I'll bet the vast majority of external data tables have an odc sitting in My Documents and the user isn't even aware of it.
But pre-tablet MS Office seemed to base their design decisions on what their biggest clients wanted. And since there really isn't a cost to the average user (other than warnings they may not understand), why not.
Related
There are many times that I wanted to save an image to an SQL Server. I have read some practices for saving images :
1) upload and save image to server, save the path inside the table
2) save image as binary
3) save image as base64 string
4) using BLOB(i haven't researched how it works)
Do you know which "way" is faster when you request from server an image?
Do you know which "way" is better so as not to make SQL server slower?
Do you know any other "way" which is better from the above?
Thanks!
Microsoft has done some research on this topic and has concluded that it depends on the size of your image. If most of your images are < 256Kb, you should probably use VARBINARY. On the other hand, if they are above 1Mb, then you should use a FILESTREAM (which is usually stored on the filesystem outside the database file).
If your images are linked to other data, it's often useful to separate the records itself from the images into different tables (i.e. create an Images table) so that the table with the data remains small and easy to manipulate.
Pls note that there is no “best” way universally but only the one that suits your specific need the most.
“Do you know which "way" is faster when you request from server an image?” – in this case #1 because you essentially store image in the file system and only retrieve image path from database.
“Do you know which "way" is better so as not to make SQL server slower?” – again #1 because it has to deal with less data. It’s easier for SQL Server to retrieve varchar representing path where image is stored than to retrieve the image itself in whatever form.
No.1 is the simplest and probably easiest to setup but pls note that there are disadvantages:
if some image is deleted from file system SQL Server doesn’t have a clue that this happened
When you delete row from SQL Server you also need to delete image from file system (if you want to keep things clear ;))
You also need to backup data from file system and not only SQL Server database
Scenario
i want to take backup from 7 client database to 1 server database.
i dont know structure of the db { either server or client db }.
both databases are having old data. now i have to make the tool take the backup for that.
and should possible to backup old data also[if any updates done on old data.]
please help to find the solution for this.
1. how can i proceed with the problem.
2. database not specified, may be MS access or Sql server 2005
3. In which i can implement this [ I am thinking of doing it in c#]
please help me to find the solution
I'm not sure why you would want to go about it this way - if you are merely trying to copy the client databases (which I interpret as being "file based") then why not simply take copies of their files as part of the wider backup strategy?
If you to write the backup stuff to place all the data in a server based RDBMS, then you are also going to have to think about how you restore that information later on - which presumably means even more coding for you.
So - I don't think this is a good idea, but if you are determined, I would start off by writing a class (which will be almost abstract) dedicated to the purpose of reading the structure of the client database (tables, fields, views etc). I'd then inherit from that to get a specific class for doing this for each individual type of client DB. Once you have that, you can use ADO.Net to read values from the tables in the Client DB, populate datatables with the information, and then write that information back out to the Server based DB.
I really can't stress enough though that I don't like this idea - it seems overly complicated, and also won't deal with functions etc.
Good luck anyway,
Martin
Advisability of doing this aside, one simple answer for a particular subset of the problem would be to create a DSN for a target SQL Server (or any server database) and in Access export table by table to the DSN. You can do this through the Access UI and it can be automated within Access with DoCmd.TransferDatabase. It can be a little fiddly figuring out the proper connect string, and you'd also need to do something about renaming the exported tables so there are no collisions between databases, but that can be handled quite easily in a bit of VBA code.
I post this only because many people overlook the Access capability to export to an ODBC DSN, which requires no writing of DDL and so forth. It may or may not make correct choices about target data types, though, so you'd have to see in any particular situation if it's good enough or not.
I want to transfer data from SQL Server table to Excel sheet using 3 tier architecture in asp.net 3.5. After user has made required changes in the Excel sheet I want Excel sheet to get uploaded and update data in the table with validation for proper data.
You could setup an SSIS package to import the data from Excel
You could either look at libraries (tons of them out there) to programmatically read and write Excel sheets, and handle it all manually.
OR: check out the SQL Server Integration Services (SSIS) - they offer neat ways to export SQL Server data into a multitude of formats (including Excel), and they also offer the route back. You can easily control and execute SSIS packages from a .NET application, too.
I can think of two methods. The first is to make an ADO connection to your SQL/Server from Excel VBA (which can be password protected). When you press a button in Excel, it either reads your spreadsheet data one record at a time and has the validation logic OR it simply uploads it with insert query to a temporary table and then you have a trigger that sees the data and processes it. That way you don't have to upload any files.
I have used ADO commands in VBA to SQL/Server and they are amazingly easy, reliable and exceptionally fast. Plenty of examples out there through Google search to find examples. It's great because you can use all kinds of Excel-specific VBA commands to build a record then update or insert it or whatever you need to do.
For security, you can limit the user (connection string and password hidden in the VBA) -- to just inserting data in a certain database so even if the password is somehow hacked from the VBA it won't do anyone any good as they can only insert.
The second method is to create an ordinary ASP upload control that accepts your Excel file when it is done. There is an event in ASP where you can run ASP.Net code when the file upload is complete. That would see the uploaded Excel file, read it through ordinary .net commands for reading Excel files (Excel automation), process it then I guess either refresh it or discard it. I do not know if there are complications running Excel automation on a server -- probably, because in essence it is running a verison of Excel.Exe on your web server (not really a good idea).
I believe you can make an ADO connection from ASP to an Excel file and do SQL queries on it. I have done that successfully but unfortunately it decides the type of the field based on the first few records and this can sometimes cause a lot of problems when reading an Excel file as a database. I suppose you could write some quick VBA to output the Excel data to CSV and upload that CSV file instead, so that nothing on the web server has to try to read an Excel file. In VBA, you can even automate the upload through SendKeys and InternetExplorer automation. I've done that and it works amazingly well. Sendkeys is the only way to populate the file upload text box for security reasons.
As you can see the first answer is the better one. That is how I would do it because that way you can also refresh your spreadsheet with new data.
I actually think you posted a very interesting question here. It's a lot easier to edit data in an Excel spreadsheet and send it back up. I have replicated a lot of that functionality using the Excel-style grid control from essentialobjects -- great software, but to emulate a spreadsheet takes a lot of coding and still it's just a Excel-like form, not a full spreadsheet.
If you are willing to put MS-Access in the middle, that can get you around a lot of these complications, but is itself an extra layer.
The way I develop may not be correct, any advice welcome.
At the moment I have a WPF application that uses a SQL2008 database. I have a copy of the database on a laptop and on my home machine. My application is versioned using SVN and I am obviously able go from the work laptop to the home machine and update/commit as required to ensure I am using the latest code for the application.
However the database is a different story in that any change I make I create a backup and then transfer the backup to the other machine etc. This way I get the data and the changes made on each system. In order to do this the database connection using a different connectionstring and I change a setting in my app to use a different connection based on my location.
I have now started to use LINQ to SQL and DBML files in my application, and finally getting to the question, I don't know how I can change the connectionstring it uses in code so it will use the correct database in the DBML.
Also, is there a better way to transfer the database so I don't need to do the backups and restores? The only reason why I have not versioned the Schema is because I am not sure how that would handle my data as this is key to my development, ie various environment settings etc are stored in the DB and brought through at runtime.
Your Statement:
I have now started to use LINQ to SQL and DBML files in my application, and finally getting to the question, I don't know how I can change the connectionstring it uses in code so it will use the correct database in the DBML.
Yes it's possible.
MYDataContext mycontext = new MYDataContext("Your Connection String");
There is a Constructor where you can chage the Connectionstring.
This is such a common problem, and I have never found a minimal and clean solution to it. How to keep all the values and variables and databases and source files in sync between machines?
Well SVN works great for the source files.
For the database, I TRY to just use one DB if we can get away with it. All the devs point to one machine that hosts the db, then we aren't wasting time with DB setup and merging. If that's not possible, then we usually just end up dumping the database when there is a change and distributing the .bak file around. You can try adding this file to SVN, and it works. you can even have the DB dump to a schedule so that SVN is always getting a new copy. But it's still too much work to keep restoring a db over and over. Perhaps you could hook in some scripting to SVN (we use Tortise for windows) and have a job that would do that automatically. That'd be nice.
For the config files - I do ASP.NET so I have web.config, connectionstrings.config, etc, I do one of two things - either just manually copy sections that need to be changed between machines and comment out the part that doesn't need to be used (clunky), or I've at times written ConfigurationSettings helper objects that diagnose a config key to decide what setting to use, based on the current machine name. eg:
Say my current machine is DEV1. The server is SERVER1. I'll have config keys with names like DEV1.connections.sqlserver and SERVER1.connections.sqlserver. In the code I'll use the helper method GetConfig("connections.sqlserver"). GetConfig figures out which key to use based on the current machine name.
Using this method, I don't have to keep remembering to monkey around with the dozen .configs every time I upload to the server or change things. But I DO have to make a duplicate key for every machine that will be running the application, which can get a bit much. For large teams, instead of using machine names, I use group names and have a config key that assigns machine names to a group - with the idea that every machine in the group will have that application set up in an identical fashion - same file paths etc.
Now onto your second question about LINQ - when you create a linq dbml, it will add a connection string to your config. you just have to make sure that you find this connectionstring and copy it into your active application. eg:
I have a solution that has 2 projects:
1 - website
2 - library
I put the dbml into the library project. If I go and look into the App.config of the library project, I'll see the connectionstring that LINQ wants to use. If I copy this connectionstring into the website's connectionstrings.confing file, when I reference the library and run the website, LINQ will be able to see the connectionstring it wants to use.
You can try Sql Server Merge Replication and use SQL Compact 3.5 as your laptop database and use master as your work/home machine database. However you may do this with only Sql Server Standard Edition.
Other option is , Microsoft Sync Framework.. here..
http://msdn.microsoft.com/en-us/sync/default.aspx
You could use red_gate's SQL COmpare and SQLDataCompare to script out changes to the database. You should be in the habit of scripting database changes anyway as that is what you will need to do when it is time to move changes to prod. I would also make sure all database changes are in SVN, we don't make any changes to the database ever without a script in source control.
I ended up just using multiple connection strings and then manually changing the connection on the dbml file whenever I moved locations. However I also have some code in place to programmatically change it based on the project setting for the location.
I haven't really got a good solution to the transferring of the databases and continue to use the backup and restore method.
I'm currently on a non-IT project that currently has data which requires some systematic analysis (mathematical formulas). The data is currently stored in Excel but it's a pain to manually enter/massage data in Excel to do the analysis.
Would it be better to store the data in MS Access and use Excel to query Access? In other words, store the data in access and do the analysis in Excel. Being able to do SQL queries on the data would also simplify the analysis.
If so, do any of you have websites/books that describes how I would go about querying Access from Excel?
You're talking about Access for entry and editing of the raw data. Then doing your advanced computations in Excel with Access feeding it the data.
I think that's an Excel-ent strategy because you're taking advantage of the strengths of both applications.
As to how to query Access from Excel, this page provides detailed clear instructions:
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6112813.html
I found that one from Google by searching for "excel query access". That was the first link; check the others if you want more information.
I think there are a lot of advantages to storing the data in Access. If getting at the data with SQL will be helpful, then it's a no-brainer. Other than that, you can store the data in Excel just as if it was in a database, but it will be up to you to enforce normalization and data integrity. If you put it in Access, Jet will force you to do it (assuming you set it up properly).
For Excel 2003 and prior, I have a page with lots of pictures. http://dicks-clicks.com/excel/ExternalData.htm
Also, if you're comfortable entering your own SQL, do yourself a favor and download QueryManager from here http://www.jkp-ads.com/download.asp It will allow you to edit your queries much faster than using MSQuery.
Yes, it would be better. There are many different paths you can choose from. Here's an option you may not have considered:
Open a new Access file
In that access file, make a link to the Excel file where your data is stored. (Go to Tables, right click and select "link tables")
Query as you need and copy/paste your results to the same XL file (but on a different tab) or to a second Excel file.
This way, you can leave your raw data in Excel if you're more comfortable with that, but still run SQL queries.
Regarding your second question, you don't need a book for that. In Excel, you can go to Data->"Import External Data"->"Import Data" and automatically pull data from your Access queries straight into Excel.
I hope this helps.
Edit: I also recommend that you google advanced Excel functions like Sumproduct, Sumif, and Countif. Depending on your analysis, these 3 functions may allow you to skip Access entirely.