I am using access 2007. In the database I am using a delete query to remove data from a table. What shocks me is that even though I have create multiple duplicates of the database in several different locations and with different names on the same server PC, the minute I run the delete query it removes all other tables on the other databases which I do not wish for as they are backups.
Could someone please help to explain why my delete query is not limiting itself to one database.
Thanks
Found my answer. The database was broken up into a back and front end. Making duplicates of the front end still was linked to the original back end. Had to copy over tables from back end to front end to make the database a single entity again.
Related
I have three identical tables, one on MySQL, one linked to this one on Access by ODBC, and a native in the same Access database.
When I update the table on MySQL, the linked table on Access updates, and vice versa. But I would like to know if it is possible that the linked table updates the native table (and vice versa)?
Access table
MySQL table
It really depends on how the local Access table is being updated. If it is ALWAYS updated say by a few forms, then you could add a after update even to those few forms, and put in code to update the MySQL table.
Another approch (again you only/always update the local tables) is to add a table trigger to the local table. In this table code event, you can actually have it call some VBA code, and that VBA code could then update/insert to the linked MySQL table. Once again, then the two tables will automatic remain in sync.
The other possible would be to add a time + date stamp column to the tables (both on MySQL side, and on the Access side). You could then write some VBA code to sync up the tables. Such code is not too hard, but in a multi-user setting, this can become quite a challenge, since while you are syncing the data, other users might also update the MySQL tables and thus your sync routines might well miss some tables. Database sync software and this subject can fill a few books the size of medical texts, and is a VERY complex subject.
However, why not just always use linked tables to MySQL, and be done with any requirements to sync data? Access makes a great client to SQL server or MySQL. If you eliminate the local tables, then you eliminate the need to sync your data.
I am unsure about the best way to do this. As I'm getting ready to put a new database into production, I need to import data from the old database that has been formed in the meantime of me working on it. The new database now also contains a lot of fake data that was used for testing, which I have to get rid of, so a fresh complete re-import seems reasonable.
Now, truncating all the tables in the new database cannot go through, because the foreign keys prevent it. Simply deleting the data instead would solve that problem, but it leaves the AUTO_INCREMENT indexes to the values where they were, so it's not a "proper" wipe. Now, there could be more properties such as that one, that would be left over (so to say), but this is the only one that I'm aware of.
So my question now is, how much of a problem could these "leftover" pieces of data pose to performance, if I were to go with the simple DELETE solution?
And also; is there a way that would be more thorough in cleaning it out, and also allow me to, of course, keep the defined constraints?
First i would use some gui tool to create the dump for the old DB ( like mySql workbench, or what ever you prefer ). Check options "Export to self-contained file", and check "Dump stored procedures and functions","Dump events" and "Dump triggers".
Then get create scripts for all tables not included in the old DB.
You can do this via "reverse engineer" option.
If you have trouble with this part this post will help.
How to get a table creation script in MySQL Workbench?
When you have old DB dump and create scripts for new sql tables, combine them to a single sql file.
On the first row add:
SET FOREIGN_KEY_CHECKS = 0;
On the last row add:
SET FOREIGN_KEY_CHECKS = 1;
Run the script. As a result you should have all tables ( new without data and old with data ), with all relations set properly. Hope it will work for you.
I'm implementing my first Access Database. I've read numerous guides/manuals, and I believe I'm nearly at the finish line. The Access Database will be used by 3-4 users.
I have three tables, all of which are "live" connections to three different Excel file. These Excel files are on a shared drive, which are to be updated periodically by the different users.
I have a single query that uses each of the different tables (3).
The goal is to give the users the ability to view the output of the query. From my understanding, the best way to structure Access is to split the database. I'd like the three tables to be stored in the "Back-End" database, and the Query to be on the "Front-End" database.
The issue that I'm running into is that, when using the "Database Splitter", I'm given the error "There are no tables in this database. The back-end database will be empty". I've searched for the past couple hours, but I can't seem to find a reason for this error. I believe it is quite clear that I do indeed have tables. What am I missing? Any input/suggestions are greatly appreciated!
The "Database Splitter" can be used when you have tables and front-end things in your database. The "Splitter" would then create an additional Access database, "move" the tables to the new database and create linked tables in the old database that map the the tables in the new database. You already have linked tables, so there's nothing to split (your linked tables are not even Access tables).
I am having a weird problem with mysql. I am developing a visual application on C# that stores data into a database. Previously I used SQL for the Database, but my client changed his mind for mysql. So I recreated the same schema on mysql. Now it is happening a really odd thing: My tables are completely empty, but when I execute the views, they return me back data from the old SQL tables, when I read directly from the tables they appear empty. The user that I use to connect are different and the most strange thing is that it happens even when I execute the view on mysql workbench. I have even truncated the tables in mysql and still the same thing. Does anybody know what may cause this anomaly and how to solve it?
p.s. Workbench version 6.2; Sql version SQL SERVER 2014
Regards.
In MySQL, a view is a virtual table based on the result-set of an SQL statement.
It contains rows and columns, just like a real table in your database. The fields in a view are fields from one or more real tables in the database.
When you execute the views, they return back data from the old SQL tables. It is because your view still contains the data you run a while ago. You have forgotten to Drop your View every time you execute it. To Drop a MySQL view, try this one:
DROP VIEW view_name
Views do NOT contain data of any kind -- except for Materialized Views and MySQL does not have those. If views had to be dropped and recreated every time a DML statement was executed on a table, views would be utterly useless.
The only time a view can return old data is when one process changes the contents of a table used in the view and the view is queried by another process before the first process commits the changes. You have not specified how the tables are being changed and how they are being queried. Nor have you included the create view statement. You could well be using other tables than what you think. This can happen during initial design of a database if tables are being slapped around like mad.
I'm trying to most efficiently manage a database table and get rid of old entries that will never be accessed. Yes they could probably easily be persisted for many years but I'd just like to get rid of them. I could do this maybe once every month. Would it be more efficient to copy the entries I want to keep into a new table then simply delete the old table. Or should a query manually delete each entry after that threshhold that I set.
I'm using MySQL with JPA/JPQL JEE6 with entity annotations and Java persistence manager.
Thanks
Another solution is to design the table with range or list PARTITIONING, and then you can use ALTER TABLE to drop or truncate old partitions.
This is much quicker than using DELETE, but it may complicate other uses of the table.
A single delete query will be the most efficient solution.
Copying data from one database to another can be lengthy if you have a lot of data to keep. It means you have to retrieve all the data with a single query (or multiple, if you want to batch), and issue a lot of insert statements in the other database.
Using JPQL, you can issue a single query to delete all old statements, something like
DELETE FROM Entity e WHERE e.date = ?
This will translated to a single SQL query, and the database will take care of deleting all the unwanted records.