I have just started an internship in I've had to learn a lot on my own. I'm learning MS SQL Server, but having a strange problem. I have a DB that has four small tables. Each one has a script to drop the table, recreate the table (I've avoided FK dependencies for the time being), and execute a demo query.
Problem 1: When I first started SQL Server Managmenent Studio would execute the script, but one table didn't show up in the Object Explorer. If I tried to execute a demo query from the same .sql file, it executed with no problem. If I tried to access it from another .sql, the table didn't exist. After many times of successfully executing the script, it finally just showed up.
Problem 2: Similar problem. When I updated one table, the changes wouldn't be reflected in queries.
Problem 3: Queries will fail, but if I click execute again with no changes being made, it will usually work correctly.
Problem 4: When I use an alias for a field name, sometimes the alias is recognized and sometimes it isn't. I've literally had single query in which the alias would work in one place, but not work in another and I had to use a fully qualified name.
I've tried the refresh and refresh local cache, but those seem to have no effect. If I exit Management Studio, that seems to usually fix the first two problems.
Am I going nuts or am I just in the dark about some weird specifics of SQL Server?
First of all, when you make a schema change you need to right-click on the "Tables" node for the database in management studio and hit refresh.
If you change a column or something in a table, right-click the table and refresh.
The refresh local cache only updates the intellisense stuff, and the refresh only updates the GUI. If you modify a table with SQL and do not refresh it in the UI, the query can still use the updated table.
If you query fails, you either have a bad query or it's not pointed at the database or connection you think it is.
For aliases, there are places where they will not work (update statements, for example) but if you don't post queries where they don't work we cannot read your mind and tell you what's wrong.
If you have specific queries that are failing, post them.
Related
I have a fairly complex database that has worked for quite a while. Today I went to troubleshoot something and I got a non-sensical error.
In my macro, first I create detail tables. Then I number each row sequentially in the detail table with a VBA script. Then I create a summarized version of that table including the just the key info like SKU and row number. (The rest of the details are added back later using the row number). The numbering script is working. The detail tables have the row numbers. However the summary table does not have the row numbers after running the macro. If I manually click the queries to add the summary tables, the numbers magically appear.
Please help. This database has worked for over a year without this problem.
Honestly it sounds like its corrupt. MS Access uses the Jet Engine which is known for bloating dB size and quite easily becoming corrupt.
You can see by the odd behaviour, the program is having trouble with the underlying file. If you open a new Access DB it won't exhibit the same problems.
The best bet is to recreate the dB from scratch or port it to SQL Server, PostGres, MySQL, SqlLite etc and put the application logic in a program - even if its a VB6 app, though I'd recommend .Net.
I've got the code to strip out every thing and recreate the MS Access dB here:
https://stackoverflow.com/a/16158027/495455
I may have a workaround as a temporary fix, but this is going to cause problems if I can't get it fixed for good.
I have a query in MS Access that works just fine when it's run on its own, but when I run it using the CurrentDb.Execute command, it gives the error "Run-time error '3146': ODBC--call failed."
I also checked if it fails if it's run from the Immediate window, and it does fail then, too.
The query calls from three different tables plus one local table that was designed by the VBA script. The VBA script works if one particular table is removed.
I know this is very generic, but why would the query work everywhere except if it's called from VBA?
UPDATE: The original question was poorly worded, and I apologize for that. It was written on-the-fly and I was frazzled by the problem I was having.
Here, I think, is the problem in a nutshell: If VBA calls a query that pulls from too many tables (3 or more) on my company's server, it gives the "call failed" error. If the query is just double-clicked, it runs fine.
Now that I'm thinking about it, could it be a server-side issue?
The workaround that I've put in place is multiple queries that create local tables, then running the original query pointing to the local tables instead of the server tables. It works, but is a very time-consuming process, both in writing the code and running the code. For this specific project that I'm doing right now, it'll work, but it would really be good to be able to get this working properly.
I had this issue due to Access having a more functions available from Access than I could use through a SQL statement from Excel. So I would check any methods you're using in your query and see which ones don't work outside Access.
It would be helpful if you post your query so we see its syntax.
But several issues to explore:
CurrentDB.Execute is only for action queries (append, update,
make table). For Select queries, use linked tables or recordsets.
Link your external tables into the current database so they can
be available as any other local table. Access can connect to other
Access files, Excel sources, or any ODBC/OLEDB compliant database (Oracle,
SQL Server, MySQL, etc.)
Use ADO or DAO recordsets to pull in your external data and then
connect the queries locally as needed in VBA.
Consider the following scenario:
One PC is running an Access database. An old legacy script will copy over all the contents from this Access database to a SQL Server (A) over LAN. But before it does this, it will delete all contents from the destination database, so it doesn't have to deal with existing records. Previously existing records are never altered.
On the SQL Server (A), replication is defined and it acts as a publisher. It will publish/replicate the data to SQL Server (B) over WAN.
This all works very well, but the only problem I'm facing is when there's a problem during the copying of contents to SQL Server (A), SQL Server (B) will be empty or missing records, even the records that were replicated a long time ago.
There are two solutions I've already considered:
Adapt the legacy script to only copy over new records, since the updates are incremental of nature.
Configure the replication to avoid DELETE statements.
The first solution is in this scenario not possible. The application is closed-source, and there's really nothing we can change.
The second solution would be ideal, but (A) would try to replicate records that already exist on (B), and I'm not quite sure how to handle that.
Surely there's a sound concept to this problem, I just haven't figured it out yet..
In SSMS go to Replication -> Local Publications and right click on your publication and select Properties. In the Publication Properties window click on 'Articles' and select the relevant article. Go to "Article Properties" and select "Set Properties of Highlighted Table Article". In the article properties window, change the "DELETE delivery format" to "Do not replicate DELETE statements".
After the change click OK and you will see a prompt. As the article property has been changed the subscriptions need to be reinitialized. Click "Mark for Reinitialization" which causes the snapshot to be applied to the subscriber.
In SSMS, navigate to Replication and right click and select "Launch Replication Monitor". Go to your publication and click View Details to see the snapshot progress.
Hello everyone I'm using SQL Server 2008 Management Studio. When I change my database table and try to save changes I got this error
saving changes is not permitted.the changes you have made requires table to be dropped and re created.
And I found that by turning off the prevent saving changes option I can avoid this error. But my question is what are the problems I may face in future by turning off the prevent saving changes option? Is there any other method to avoid this problem?
If you turn off saving change i asume that no change will be made to the table. In my experience, SQL Server Management is not the best way to make changes to an existing table, especialy if got data on it. You will find many cases in wich gives you this error and you have to manualy write the ALTER TABLE to make the changes you want. So my advice is always to use ALTER TABLE. Hope this help.
I wonder how management studio generates the change table scripts each time i change a table, especially when i change the datatype from 'text' to 'varchar(max)'.
Peace,
Ice
Update: Concerning the already given Answers i want to precise my question, after say thank you for your posts.
Now, it is like already said, ssms generates the scripts on demand but i want to write a script to identify all the tables in a given database with datatype [text] and change them to [varchar(max)]. So the easy part is to scan the dictionary to find the tables and columns, the harder part is to generate the mentioned scripts which copies all the rows into the new structur.
--> Yes i can work manually thru the list of tables and click in ssms to get the scripts, but there are almost 200 tables... better a computer do that work, isn't it?
If what you're asking is "Given a table, is there an easy way to get the DML used to create that table?" then I don't believe you can just run a system SP and get it. You'd need write something that selected from the system tables to get columns and datatypes, indexes, and everything else.
I wish there was an easy way to generate the same scripts SSMS does (like right-click -> "Modify" on a stored procedure), but it doesn't seem to be that easy.
When you change a table using the Management Studio table designer, the script is already prepared in the background, and you can simply click on the "Generate change script" icon to view it (and copy it if you like).
In SQL 2008, the "Generate change script" option is in the "Table Designer" menu.
If you're asking what it does, it's quite simple: SQL will create a new table with the new structure, copy all the data from the old table, drop the old one and rename the new one. If you open the script as described above, you'd see that.