|
I am currently writing an application which connects to a Microsoft Access 2007 database. After doing a bit of research, I have decided (and I have been given the go-ahead) to work on transferring everything over to an installation of Microsoft SQL Server 2008 Express. I am successfully able to import the existing data into SQL Server via SQL Server Management Studio Express. I set up all the table relationships and so forth.
My question is in regards to the relationships. There is one main table, which is the basis of the application's data. The fields in that table, Repairs, include relationships to other tables (e.g. [Failure Codes]). In Access, the linked fields are setup as Lookup columns, pulling data from the appropriate tables. The fields display the [Failure Description] field (text) in the Repairs table, but of course the field's value is the [ID] (Primary Key) from the [Failure Codes] table.
Is there any way to do the same in SQL Server? This is not the most important issue. It is simply a curiosity.
The main thing is that my boss is most comfortable with Access. He has never really worked with SQL Server. I told him how we can create an Access database on his computer which will link to all the appropriate SQL Server data (I tested it, it works perfectly). However, when he views the Repairs table he is seeing the [Failure Codes].[ID] value instead of how it was before, displaying the [Failure Codes].[Failure Description] field text while storing its value as the [ID]. Is there a way to change this? He often runs queries to find records matching criteria such as a date or date range. And when he does, Access pulls the [ID] instead of the description text.
The main reason I ask is for the fact that he generates reports periodically. I know he uses the Report Wizard in Access. However, when doing so, the report displays the [Failure Code] column's values for each record as the [ID] rather than the [Failure Description]. Now, I know how to add more fields and such to the report, as I am sure he does as well. But are we missing something? Or is it best to put the fields in manually, in order for them to look up the appropriate values?
|
|
|
|
|
You will have to develop forms/queries etc to display the data as you would like to see it. Access allows you to cheat a little by automating this from within the table design.
As an aside, you should NEVER EVER EVER let someone have direct access to the tables - it's a recipe for disaster...
|
|
|
|
|
I figured it was an Access "cheat" rather than some sort of standard so to speak. But it didn't hurt to ask. I will just make sure he is aware of the fact that he will need to modify the reports a bit to show the data that he wants. Well, I guess a query, as you suggested, would come into play there as well, correct? I mean, create a report that pulls its data from the query, which displays the data as he would like to see it?
The only people who have direct access to the raw data (tables and the like) are my boss and myself. He created the original Access database which I am transferring over to SQL Server. The rest of the employees will use the application I am writing.
Sorry, I'm quite new to the more intermediate-advanced database techniques and such. 
|
|
|
|
|
Nothing to be sorry about - everyone has to start somewhere!!
For a report, you can create a query that has the data as you want it (ie: link the two tables together in the query, and instead of showing the ID field, show the related field that has the text description). This has the benefit that if you export the query to Excel the data will still be formatted correctly.
On a form (this works for a report also, but you don't get the benefit with exporting that I referred to), you would have a query that returns the raw data for the form, then a combo box (with its own query to get the data from the related table). Set the data source for the combo to the related query, and bind the combo box to the id field in the main table.
Hope this points you in the right direction!
|
|
|
|
|
Alright, thanks for the help! I understand completely, it makes sense entirely. I can probably handle it from here, at least for awhile. But I'll return if anymore assistance is needed.
|
|
|
|
|
Good for you Matt, you have a learning curve in front of you but it will definitely be worth it. When you have the database and app working it will be a natural step to move the report(s) to a proper platform (SSRS or Active etc, NOT Crystal Reports).
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Now that you have the data in SQL Server you need to create the Views (these are something like queries). In the view you have the main table and add in all the tables that have foreign key (lookup) connections to it. If you use the view designer SQL will create the link for you.
It is important that when creating a view the view has the same number of records as the transaction table, this tells you that your joins are correct. Then just add in the description fields you want the user to see.
The access app should use the views instead of the tables to see the data.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Thanks. I had partially figured that out on my own, before seeing your message. But now I'm even more on the right track.
I received the approval to migrate to SQL Server. So this afternoon I installed an instance on one of our server machines at work (SQL Server 2008 Express). And I can manage it from my dev. machine via SQL Server Management Studio Express. I setup a few views and played with them in Access prior to that. And what you just told me will help when I go back to it.
BTW, I now know why I was told to get away from Access. Displaying a Windows Form using data from a query could take 5-15sec., maybe even 20sec. Since I migrated to SQL Server, the same operations are practically instantaneous. :-P
About the reports. I actually created my own report generation (for weekly and monthly reports). My boss basically said he doesn't require the ability to design the reports himself, but rather he simply needs specific data in preset designs. The weekly and monthly reports, as far as I know, are all he uses. In doing so, I also learned quite a bit about LINQ To Objects today. I've been interested in learning more about it, though I hadn't taken the time to until today. It made manipulation of the report data so much easier and so much quicker. Then, as requested, I designed the reports in PDF format using iTextSharp.
Is there any general advice you have for using SQL Server? I mean, any tips to maintain good performance, security, etc.?
|
|
|
|
|
Matt U. wrote: I mean, any tips to maintain good performance, security, etc
Well there goes a book or 2 
To be honest your data requirements are probably so low that I doubt performance will be come an issue. It is more important to get your structure correct, only store data once being the basic rule.
SQLServerCentral.com is an excellent resource for articles and tips, I'm not sure how good their basic info is.
I would concentrate on your presentation layer and reports. You'll get the biggest bang for your buck there. User really don't give a rats about the database but will argue over the width and colour of a textbox.
Matt U. wrote: iTextSharp
This is only a PDF generator, not a report generator. You will at some time need to look into proper reports, I use SQL Reporting Services, the option to embed a report in your app without haveing to use the Server component is excellent for small apps.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: User really don't give a rats about the database but will argue over the width and colour of a textbox.
LoL. I wouldn't be surprised if I received some sort of similar feedback. There are quite a few weirdos where I work. xD
Mycroft Holmes wrote: This is only a PDF generator, not a report generator.
I am aware of that fact. What I mean is I create reports based on data, using iTextSharp to lay the data out in a PDF. The reports are basic. For each new "Model" in a list (of records from the current week or month), it pulls each record for that model. Certain fields are then retrieved and laid out in a table in the PDF file. At the end of each model there is a "Summary" section, which simply sums that model's data up, total handled, total repaired, etc. It works just fine.
Does it sound like I should still use SQL Reporting Services? And if so, do you have any good resources for it? Before I created them myself and placing them into PDF I had researched reporting a bit. I couldn't really find any good material that taught the subject well enough for a "beginner". And I didn't find much useful on SQL Reporting Services specifically, as I had seen it mentioned in numerous places.
EDIT----------
Well, I don't know what I was thinking before. Maybe I did not search correctly. I just found numerous tutorials on SQL Reporting Services. Haha. Thanks a lot, I will read into it now.
|
|
|
|
|
Make sure you don't get into the Server side of it, you don't need it yet, concentrate on "local" reports or RDLC these are the embedded version (same report just delivered without the server).
SSRS exports in PDF format, among others.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
What tools will I need in order to create SQL Server reports? I can't seem to find that information. I saw "Report" in VS2010's "Add New Item..." dialog box, with the "RDL" extension (or whatever it is; I know I saw it, just can't remember it). The main thing I could not figure out was how to populate the report. I saw the report design view and such. But I can't figure out how to add data controls and bind them to data. My application does not use a generated DataSet. I have a connection class which handles all the retrieval of data from the server.
|
|
|
|
|
Reports is a fairly steep learning curve, after adding the report you then add a data source and design against that. I always create a stored procedure that service the data requirements of the report. This is then usd as the data source.
When you have completed the design you cahnge the extension to RDLC and supply the data from your application by getting the data from the stored proc and passing it and the rdlc to the report viewer.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Alright, that sounds reasonable. I will look into it more. Until then I will use my current "report" generation.
|
|
|
|
|
I am seeing a weird behavior in reading a column(of type TIMESTAMP WITH LOCAL TIME ZONE) from Oracle 9i version as compared to othe versions of Oracle (10g and 11g). I have developed a windows client which connects to the foriegn database(ORACLE) and do the transactions(WRITE and READ). Though the value which is written(storage value) is same in all the versions, the value which I read from the database is different wih Oracle 9i. If anyone has faced this issue, please help me resolving this. Thanks in advance.
|
|
|
|
|
..and what's the timezone set to? Checked "Daylight Saving Time"?
Bastard Programmer from Hell 
|
|
|
|
|
No, the Daylight savings time is not checked. The timezone is set to 'US/Canada' "-5:00 Hrs".
|
|
|
|
|
|
|
From SQL Server Management Studio 2008 R2: you can RT-click the database in question, choose Tasks -> Generate Scripts and select the objects you'd like to script out that way. There is an option to save each object to a separate file ("single file per object" option, I believe).
|
|
|
|
|
I have an SQL Server 2005 Express instance which has a database on it and no problems - all the data is visible and everything works.
I have just created another database and in the Visual Studio environment everything is fine and I can 'see' the data.
If I compile the setup and install the program on the same machine the program sees no data at all. It has to be something to do with these User instances I am thinking, yet I have not (knowingly) invoked one.
Both have an identical connection format:
Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=" & strDatabase & ";Data Source=" & strServer & ";Type System Version=SQL Server 2005;MultipleActiveResultSets=True
In the development environment there are 'jobs' set up but it does not see them in the 'non-development' environment.
I have checked the properties of both databases and I cannot see any differences between them.
I am stumped and could do with someone to come up with the magic solution!! 
|
|
|
|
|
Rephrasing your question to be sure I understand it.
You have a SQL server installed on your local box (no other.)
You have data in tables in that database.
When you use SQL Server Managment Studio you can see the data in the tables.
You have a program which when run in Visual Studio produces data from the tables.
When you run the same program from the command line, on the local box, you do not see the data.
If all of that is true...
Are you catching exceptions and ignoring them?
|
|
|
|
|
Yes pretty much true. The program is a windows exe. No I am not ignoring exceptions, they are written to the Event log - and there are none.
The program runs just fine, but there is no data visible, in other words when I go to the configuration screen which draws its data from the SQL Express database there is no data, yet it is there running inside Visual Studio. It is as if the database is fresh with no data in it.
|
|
|
|
|
Then you are making an assumption which is not true.
The following are possible assumptions. There could be others.
- You are connecting to different databases.
- You are connecting to different servers.
- The data in VS is not commited.
|
|
|
|
|
Sorry what assumption am I making?
There is only one database
There is only one server which is the machine the program, VS and data are on.
The data in VS is not committed because it is already in the database. I am reading it not writing it.
Thanks for your time on this one but I have decided to change over to MySql. I can't be doing with the vagaries of Microsoft.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
