Am trying to import some selective data and create a table in MS Access db 2002 from a linked table. For some odd reason the performance became really bad all of a sudden when importing the data.
I tried googleing and tried various methods like reparing/compacting the db, Changing the SubDataSheet Name to [None] from [Auto] but either one worked.
Can any one please give me some examples to increase the performance of linked tables.
Thank you.
Rather than selecting information from a linked table and trying to make a local table, when using a database server like MS MSQL, you would be better to create a "Pass Through Query" to do the select work on the server side, and then carry out a simple select * on this pass through to get your data in to a local table. This will give the best results if your first select statement is complex and takes a while for Access to run on a linked table, if that is not the issue then you will need to look at your network speed which connects you to your MS SQL server.
Related
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 had a server running mysql. The power was cut to the machine, and mysql (I assume was forced to terminate)
Now, when I try to connect to the database again, the tables exist, but there doesn't appear to be anything in the tables, would there be any chance of a way to fix this.
When I use the SHOW TABLES command, it lists the corrupted table. When I use the SELECT * FROM [corrupted table] it says table does not exist.
I understand if it seems impossible (please let me know if so)
THANKS!
in such case we retrive a data from log file:
1) [This is first link][1],
2) [This is main URL][2]
I am using Laravel 4 to build a site that uses a large number of mysql databases, where each database has multiple tables. The structure and organization of the databases is not within my control.
I need to be able to replicate a table from one database in another database at run time (the source database and destination database (and the specific table within the source database are dependent on choices made by the user).
Duplicating a table is easy to do with mysql:
CREATE TABLE database2.new_table LIKE database1.original_table;
INSERT INTO database2.new_table SELECT * FROM database1.original_table;
but I cannot figure out how to do it with Laravel.
I can easily access each database by creating their own connections ('mysql1' and 'mysql2') but I can't figure out how to construct the statement to use both. The following doesn't work
$success = DB::connection('mysql2')->statement('CREATE TABLE new_table LIKE database1.original_table);
because I am trying to access database1 directly without using the 'mysql1' connection, and Laravel generates an error saying that database1.original_table doesn't exist.
I feel like the solution should be obvious but don't have enough experience with Laravel to figure it out. Any guidance would be greatly appreciated.
I was importing one table in a MySQL Server when the power went down. After this event I tried to query the table I was importing, but got the error 2013, only when I'm querying this table (the others work just fine).
I have physical access to the server, tried to execute any query from there (tried to SELECT, and even DROP TABLE) but still got the same error.
Does anybody know a solution where I can re-build only the table (without building the whole schema from scratch?)
I'm adding this as an answer rather than having lots of comments underneath. I must state in advance that I've not used MySQL but I have used SQL server a lot so I'm hoping that something I say may help.
You say the table is still there. Was it created as part of the operation you were doing or had it been there for a while?
What happens if someone else or a different account tries to access this table?
Is there anything on this page that is relevant to your problem?
http://dev.mysql.com/doc/refman/5.0/en/gone-away.html