I have a typical Access front-end with SQL Server back-end. I created some views in SQL Server and linked to them in Access. When I use "CREATE INDEX index_name ON view_name (field_name)" it creates a primary key even though I have not specified it to do so (and do not want it to do so). Why is that? and how can I create a non-primary key index?
How this works?
Any view, any linked table, in fact ANYTHING you hit, use, consume from SQLServer?
All indexing is setup 100% in SQLServer. The Access client side does not, cannot, and WILL not create any kind of index for you.
The create index command to specify and setup a primary key? It does not really create an index in Access but ONLY SETS and TELLS Access what PK to use.
In fact, when you link to a view, you are prompted to select the PK when linking to a view.
SQLServer views DO NOT have the concept or even a setting that tells you or EVEN LETS you specify the PK column. Part of the reason for this is in fact that a view can consist of more than one table - so which table now is to define the primary key. And in fact if your view has a join with say 5 tables? Then in fact that view has 5 different primary keys from 5 different tables).
So, when you link to a view in access, you will note this prompt:
If you don't select a column for the pk?
Then you have no PK set. However, you can use VBA to TELL ACCESS what row to be the PK setting.
So, say in above I did not select a PK when linking with the GUI. Or say I am using code to link to a view?
Then in code to set the PK value, I would and could and should execute the following command:
CurrentDb.Execute "CREATE UNIQUE INDEX IXPK ON dbo_ViewHotelsTest (ID) WITH PRIMARY"
AGAIN: Note above comments. The create unique index DOES NOT create an index in Access. Nor does it create an index on SQLServer. That command is how you can tell Access which column is to be seen and treated as the PK.
So, above command?
In plain English:
Please Mr. Access, will you set the PK column and we are using the above
command to do this.
In other words, there is no other command in code to "tell" Access what the PK is supposed to be, so the DDL sql create index command is used. But I STRESS AGAIN THIS does NOT really create an index, but ONLY tell Access what column to use as the PK.
This command results in the SAME and IDENTICAL results if you select a PK during a linking of a view.
If you want to create an index in SQLServer? Then go to SQLServer, and create your index(es) in SQLServer.
FYI:
As a further explanation, in 99% of cases you NEVER want, nor need, or even should even create an index on a view on the SQLServer side of things.
In EVERY case, if the base table used for the source of the view has an index that can be used, it WILL IN ALL cases be used if you build an on-the-fly query, build a SQLServer side view, or even create a sql stored procedure. IN ALL cases, a simple create of an index on the base source table (using SQLServer tools) will suffice, and in ALL cases, include views, and including linked view from Access will automatic use ANY and ALL existing indexes on the base table from SQLServer.
So, not only is there zero requirements to EVER try and create an index in Access on linked tables (or linked views), but in fact it not even possible. Of course the create index command DOES need to be used to set the PK column when linking to a view.
If you link to table, then Access can figure out which column is the PK, and will set this for you. But SQLServer does not have a setting, nor even the concept of a PK column for a view, and thus you have to select the PK during linking using the GUI, or as noted, you can in code execute the above command that tells access which column to use as the PK, and as noted, that command does not in fact even create an index, but that command is ONLY to tell Access client side which column to see/use as the PK.
You can for views that don't require you to "update" the data. So, a linked view without you selecting (or better said "setting") the PK column will be read only.
So, if you using the view for a combo box, or say just a report? Then you don't care, and don't need to set the PK for that view, and it will be "read only". So this means that you ONLY need to set the PK column for a view if you need to update that view (say in place of updating the base table that the view is based on).
So, in summary:
that create index command does not actually create an index.
That create index command is ONLY required if you need a linked view that allows Access client side to update such views. Without the setting, then the linked view will be read only. So the purpose, the act, the role, the "thing" that create index does on the linked view? It is ONLY to tell Access what column is to be used for the PK - it does not actually create an index anywhere - including NOT creating one in Access client side. (So, ONLY purpose is for TELLING access which column to use for the PK. Can't really say why they use that command that way but best guess was no other way existed to tell Access what column to use for the PK - so we use that command).
If you use the linked table manager, and re-fresh the table links? Access WILL remember the PK settings for a view. However, if during linking you change the database that the linked tables point to? Then the PK settings in views will be lost during that re-linking process. (and then you have to re-execute those commands to re-tell Access which column in the linked view is to be seen/used as PK column.
You don't need to ever create an index client side for Access in regards to linked tables, or views - all indexing is automatic, and if an index exists on the server table, it will and can be used.
So, create index command is HOW you setup a PK column for linked views. In all other cases (linked tables - but not a view), then that command is not required, and ANY and all existing indexes that exist and were created on the server side table will be used (and thus no need to try or create an index in Access, since all such indexes are handled by the server side - Access has no say, nor even control over how SQLServer uses indexes). But, a correct use of index on a SQLServer table will automatically be used by Access in the requests it makes to SQLServer. But that "job" of indexing is 100% managed by the server - not Access.
I have a requirement to provide a REST endpoint to create/delete tables for a privileged user.
When user makes a request to create table 'xyz', I create table with prefix "user_" and return response saying
'user_xyz' is created.
This way I know what tables are candidates for deletion when a request is made.
But I wish to create table "xyz" as requested by user and would like to add some label like "deletable" so that I can
query to find if a table can be deleted.
One option is adding a comment for table and but I have to query information_schema. Comment does not sound very correct.
Can this problem be solved using any other approach when I use MySql database.
I don't think you have much other options other than the one you suggest,
prefixing/suffixing table name
use table comment
create meta table with UserId(has the advantage of foreign keys)
and TableName fields (has the disadvantage of integrating the table
name with the actual very table as it can change without this
metatable being updated)
create separate schema for each user
I'm working with msyql and symfony2. I have a database with 15 tables. I want to export all data starting from a row in the main table, go to each table I have and select all data related to that and move it to another database (which is not empty) and also not loose foreign key relations.
I will try to explain it with a very basic example.
screenshot here
So I want to select the user with id 1 and from that to select all threads connected to that user and from those threads I want to select all their posts connected to them. All this data I want to export it to another database (this is not empty also) and keep the data integrity with all its relations.
Is there a tool or how can I create an export script like this?
In MySQL, using MySQL Workbench, how can you create a foreign key relationship to a table which resides in another database? After entering the 'Qualified Table Name', of DatabaseName.TableName.ColumnName, workbench simply acts like I put nothing in the box. Do I need to create these relationships only with manual query in workbench if it is a different database?
InnoDB engine allows you to define FK(Foreign Key) for tables.(even from other databases)
For this you must mention database name before table and column name. Like so :
dbname.tablename.columnname
I think I found the solution. Actually you have to add another schema in your Model which represents your 'different' database.
Then you need to create all your tables (in an EER Diagram) into this new Schema.
Finally, when you'll click on the Foreign Keys tab from the original table you'll be able to choose the right table from the different database in Referenced Table. For example different.new_table
I think it is impossible to do what you want. You can not link tables from different databases.
In SQL Server 2008 I had remade the database structure similar to Access. I need to import a couple of related tables but I am worried that the foreign keys won't match with the autonumber fields from the related tables.
You have some options here:
If you export the table to SQL Server, all the data will make it through properly and then you can set your PKs and FKs
Create the Table structure with an IDENTITY column and use SET IDENTITY_INSERT to put in the values you want into the Identity column.
Without knowing more details about your table structures and locations, I can only tell you generic things like
You will have to match the keys up manually so that the PK-FK references remain the same.
If you need to match the old access ids to the new autogenerated ids in an existing table, this is something you needed to do at the time of moving the data from the orginal table unless you happened to store the access ids. Usually I do some type of a cross matching table with the old id and the new id as part of the import process. Then you use this table to match to the realted tables to update their ids. If you didn;t do this and the ids are differnt, you will have to find a way to match them to the orginal access table first before you can import the related tables. I hope your table has a natural key in that case.
If the tables are the same you could use the rather verbosely named “Microsoft SQL server Migration Assistant 2008 for Access”. This will allow you to bring over the data whilst keeping the same keys