When first time I created my App, I created a Database using Microsoft SQL SERVER Management Studio and I connected my App with it.
I created another DB with the same tables and every thing but with diferent names and I let my App to connect to the second one because I want to make some changes and when I am trying to edit my DataSet with Wizard I get this tables page :
as you can see my app couldn't find the right tables and when I am trying to select LastWork table as in the pic, it will make the table name in the DataSet LastWork1.
How I can fix this problem? and let it find the right tables
I've seen this problem when using copies of databases as well, after pointing to a different connection in the settings area of the project properties. The XSD evidently hard codes each DbObjectName with the name of the database and schema in use at design time. One approach to fixing it is to open the wizard for the appropriate dataset, uncheck the red-x objects with the missing references, close the wizard, then re-open it and re-select the objects that are needed. This is not ideal in a large xsd if many findby queries, custom columns, etc. have been added. So an alternative is to do a find and replace on the database name within the XSD itself.
Interestingly, my experience has been that an application runs fine when the connection string points to a differently named but otherwise identical database.
Related
So I just started a new job and part of my responsibilities are to support some old Access Database applications until I can get them replaced with something better. One of the first things I noticed is that the Access Database uses Linked Tables (linked to SQL Server), but they're pointing to production. Before I made any changes I wanted to set up a test environment and point the Access file to a test SQL Server.
Here is where I'm lost. I can't figure out how to change where the linked tables are pointing to. I've seen on here where some have suggested to change it in code, but forms seem to be bound at design time and I'd prefer to make the changes in Design mode so that the Test and Prod versions run completely separate. I can't find where this is done anywhere.
Is there someone that could point me in the right direction? I do NOT want to change the connection properties at run time...
Thanks,
John
You basically want to set up a new ODBC data source to a dev or test environment then use MS Access's Linked Table Manager to point it to the new tables.
Open the database that contains links to tables.
On the Tools menu, point to Database Utilities, and then click Linked
Table Manager.
Select the Always prompt for new location check
box.
Select the check box for the tables whose links you want to
change, and then click OK.
In the Select New Location of dialog box, specify the
new location, click Open, and then click OK.
I am new to Oracle SQL Developer (about 1 month of use), having always used Toad. I have 2 almost identical schema set up - one to test older code, one to develop a modified versions. I have 2 different connections set up - one to each schema, with separate user names for each one.
But when I delete a table or column from the schema in one connection, it is also deleted or changed in the other.
This happens if I right-click on the table or field in the Connection explorer panel, or if I open a SQL Script saved to disk. If I open a SQL script, I even see a pop-up that asks me what connection to use, but if I select one, it still makes changes to both. Even if I only have one of the two connections open, the script will still change design in both of the connections.
The only way I can be sure to make changes to just one of the two is to right-click on the connection name in the Explorer panel, and open a new SQL Worksheet. The worksheet is then named for the connection and just makes changes to it.
This is not the behavior I was expecting, and I'm facing many hours of work to get the definitions of the 2 schema back to where I need them to be. I am wondering if there is some key concept or distinction I am missing or if there is some way the database(s) are set up that is enabling this to happen.
In case you never found the answer for your question. This is my understanding:
The database may have several schemas. The schema is not a separate database, it is a grouping of objects in that database. If you change something while in one schema, you are really changing it in the database, not just the schema. I hope this helps.
Are you just trying to test things in one schema? It sounds like you may want to have a Database and a TEST Database. You could test whatever you wanted in the TEST database and never have it change the real database.
I am having what seems to be a simple problem but I can't figure out how to get VS2010 to update my .xsd file when I change the schema in my sql server database.
I have found two recommendations thus far.
The first to right click the xsd file and 'Run Custom Tool'. This does not update the XSD as far as I can tell since I my added table doesn't appear and a table with a new column isn't updated.
The second option is to delete the xsd file and then re-add the datasource. This method obviously updates the tables but any queries that I added for the UI are lost.
Because this is a fairly large data model I expect that there will be changes (we are still early in the process) to the schema. At this point it appears that my only recourse will be to move my UI specific queries into that database as functions are stored procedures...
Is there a best practice for this (or something I'm terribly missing with this toolset)?
I have an Access 2003 project in which all data is stored in SQL Server 2008. I am using ADO to view/update data via forms that are completely unbound. For example, a form has several textboxes and combo boxes on it. When the form is loaded I use ADO to make a call to a stored procedure on SQL SQL, it returns a recordset and I populate the controls, via VBA, with the data from the recordset. I like this approach because only the VBA is stored within Access. No data (well actually connection strings are stored in Access, but that is it!).
My problem is what to do when it comes to reports. I want to create reports that are based off of views created within SQL Server, however I would like to avoid, if possible, static linking to the views directly from within Access. Is it possible to set the recordsource of a report dynamically at run-time to be the results of a SQL Server view? If it is, how does one go about designing the report id Access does not contain any data?
More info ... The reason I want to avoid linking to the view in Access is the environment in which the Access application could be run changes (Production, Development, Test). Currently whenever I make any calls to the database stored procedures, I look up the connection string (Active Directory based so no passwords are stored) in the only table that is stored in Access .
Thanks for any assistance.
First of all let's be clear: you don't have an Access 2003 "project." You have an Access 2003 database.
An actual Access Data Project cannot have local tables, and uses a SQL Server as the back end. When you view Tables you see the ones that exist on the server, and under Queries you see the views, functions, and stored procedures that exist on the server. You can use the "Upsize Wizard" to turn an Access database into an Access data project (or probably better, just create a new ADP (Access Data Project) and import all the forms, reports, macros, and modules.
Here are my ideas:
Convert the database to an actual Access Data Project and then just use regular old queries as if they were addressed to the local database. You can even bind forms to stored procedures and they can be updatable. To deal with Production, Development, and Test, you just change the connection string in the GUI or you change it through code like so:
Application.CurrentProject.CloseConnection
Application.CurrentProject.OpenConnection NewConnString
If you want to read the connection string from a centralized database or from a text file on a share or from a common table you load in each environment (that has the connection information for every other environment), that is up to. I have one Access Data Project that has an toolbar with an Environment dropdown. When the environment is switched, a child database dropdown is then populated, and finally all open forms are notified by an event (though bound forms close when this occurs).
There's nothing wrong with using linked tables. Just write a procedure that loops through all the tables and updates them to point to the correct server when you want to change environments. The difference between "static" linking and "dynamic" linking is just a single VB procedure that rips through all the tables and relinks them--easy peasy.
Setting a report recordset dynamically at runtime is problematic. It MIGHT be possible in actual Access Data Projects, but definitely not in regular MDBs.
You CAN create pass-through queries in an Access MDB, but I'm not sure about passing parameters in. You'd probably have to set the query text dynamically with the parameters hard-coded and then run the report. This would be a problem for a multi-user database unless each person gets his own front-end to run from.
I recommend that you go with option 1 or 2. Option 1 seems simplest but there is some learning to do before you'll become facile with ADPs over MDBs. Let me know if you think you'll go down that route and I I'll share some of the gotchas with you. However, it's probably easier than what you're doing now which is everything manually. (Ouch!) The second option would be fastest for implementing right away and not throwing any wrenches into your current skill with MDBs.
UPDATE
So if you want to link tables, here's some code to get you started:
Sub TableRelink(MdbPath As String)
Dim Table As DAO.TableDef
Dim Tables As DAO.TableDefs
Set Tables = CurrentDb.TableDefs
For Each Table In Tables
If Table.SourceTableName <> "" Then 'If a linked table
Table.Connect = ";DATABASE=" & MdbPath 'Set the new source
Table.RefreshLink
End If
Next
End Sub
This code is for MDB files, but some digging will quickly give you the correct properties and values to use for SQL Server linked tables.
Another Thought
I just thought of another possible way to handle just the problem you're experiencing: Use a session-keyed "temp" table in Access. Create a local table that has all the columns the view returns, plus a GUID column. When the report is run, insert the contents of the view to the local table, keyed by a new GUID value. Set the recordsource of the report to SELECT * FROM MyViewTempTable WHERE GUID = '{GUID}'. Simple problem solved. On report_close, delete from the table. Perhaps put in a date also and delete after 10 days in case any rows get left behind.
I have a number of reports deployed to a SQL Server 2005 Reporting Services server. They were all developed using the same Report Model (SDML) that references the same Data Source View (DSV) that points to a test database filled with mostly dummy data. Now, I would like to make those reports pull data from the live database with our real data instead. The two databases have exactly the same structure.
It seems to me, that if I could just change the Data Source being referenced in the Data Source View, then I could redeploy the report model, and all the reports based on it would also reference the correct data. I can see in Business Intelligence Development Studio 2005 that there's an option in the Data Source View property list in Design mode to change the Data Source. So I changed the Data Source, thinking that would work. However, when I try to redeploy the report model after changing the Data Source in the Data Source View, I get a number of error messages like this one:
Error 1 The Table property of the Entity 'Address' refers to the Table 'dbo_address', which is not in the primary data source. Events.smdl 0 0
Is there something else I need to be doing here? Something in the Report Model or Data Source View that should be updated? Is there another way to do what I need to?
Edit 1:
I tried changing the datasource of the report model on the server after the reports were deployed, and that seemed to work pretty well. It's not exactly what I wanted to do, but it works. Thanks everyone.
The strategy that has worked best for me is to deploy the "test" shared datasource to the server then edit it via the Report Manager interface to point to the "production" database (changing the connection string). Making sure of course Overwrite Datasources is set to false on deploy.
Also, your database schema must be the same in test as it is in production.
I don't have as much experience with the report models but generally SSRS doesn't like it when you make changes to the datasource and asks you to refresh all the datasets that you have if you do.
Alternatively, just change the datasource definition on the report server itself.
It sounds like you're changing the data source that the dsv references. Instead, why don't you try to change connection string of the data source. Internally the DSV uses GUIDs to identify the various tables and fields, I suspect that by creating a new data source the GUIDs will change and that is why you're seeing these error messages (as the error message is mapping the internally used GUID to it's "friendly name").
The setup I use has an identically named Data Source (.rds) file for each environment, in the same folder the reports are deployed to. It's just a connection string...
My experience has been the same as zalzaw's - if you change the Data Source, you have to refresh all the datasets associated with the report while pointing at the new environment based on the data source changes. It's very tedious - you go to the Data tab for the report in Business Intelligence Development Studio 2005:
Select a Dataset from the dropdown menu
Click the Refresh button (2nd to the right of the Dataset dropdown, icon looks like recycle)
Repeat steps until all datasets have been refreshed.
Make sure that the database(s) (and stored procedures) are in sync. It's all for naught if a table exists in Dev but not in Test or Prod...