I have read through all the available documentations about file table on SQL server. One thing it has not mentioned is creating additional indexes (non-unique clustered index in my case) on a file table fixed schema.
Am I right to say it is perfectly fine to do that and it wouldn't cause any issues? If it is an issue what is the best approach?
According to the Create, Alter, and Drop FileTables topic in the SQL Server documentation (emphasis mine):
Since a FileTable has a pre-defined and fixed schema, you cannot add or change its columns. However, you can add custom indexes, triggers, constraints, and other options to a FileTable.
So you should be fine adding custom indexes.
Related
When I migrate from Access 2003 to SQL server 2019, I get half of the tables empty. What can cause this problem and how to fix this? Tables are not empty in Access.
Ok, so at least SOME tables are going to sql server. This is good, as it shows at least you have "some" of this working.
The tables that don't go? Often this is for two reasons.
the table(s) have bad dates - but SSMAA should spit out a error in that regards.
the other issue is if the table(s) in question have mutli-value fields (attachemnts, or a multi-select type of column. those columns are NOT supported and SQL server has no such data types, so they can't be migrated.
So, you might want to take a look at the offending table, see if any lookup-ups are defined for some of the fields (you can while in design mode - click on the lookup tab - see if a query exists). So, you need to un-convert such tables.
So, in the lookup tab, you see this:
So, as a general rule, you have to remove those columns. but, they are in fact a "hidden" table and relationship. So, in general you have to create a new child table, and fill out the related data BEFORE you migrate such data.
I am evaluating outsystems and am trying to write a PoC List/CRUD app based on a legacy database table (the structure of which cannot be changed) which does not have a primary key but instead has two text fields that together constitute a unique index. The database is SQL Server 2014.
The table is successfully added in Integration Studio using "Connect to External table or view".
Then when I open the TestApp in Service Studio and go to the data tab I see the entity there, but it's not usable because it has no identifier defined. I have read some online info that I can double click on the entity and go to the Indexes tab. Here I normally would expect to see the index already defined in the database but it's not there. I also expect to the the New and Delete buttons to be enabled so I can create and delete indexes but New is disabled.
Am I correct to assume that OutSystems should have already "seen" the existing composite unique index? If so, am I correct to assume that this index would have sufficed to create a pseudo/virtual identifier for the entity, whereby making the entity system happy for CRUD and List operations? And also why is the New button not enabled for me to even manually create the index?
Can someone help me please in the correct direction?
Thanks
The OutSystems platform only supports single primary keys, so you have to create the CRUD operations by hand.
For external entities, index information is not fetched from the database, and the reason you can't create the index is because OutSystems doesn't control the metadata (i.e. you can't create indexes, create/modify columns, etc).
In Grails you can add custom indices to your domain classes.
Does Grails generate indices by default for my tabels?
Is there a rule which columns I have to use for my index?
Do my queries change when an index is set?
This isn't really a Grails question, except for the part about when and if Grails creates indexes. You need them like you would in any application that uses a database - create them to improve lookup performance.
Grails doesn't actually create any, Hibernate does that when it generates the DDL that creates your tables. You can see this DDL at any time by running grails schema-export - the generated file will be target/ddl.sql.
In general you'll see unique constraints which will typically create a unique index, and in MySQL and some other databases you'll see indexes created on foreign keys (but this isn't done for Oracle for some reason).
There is some mapping support for getting Hibernate to create indexes as you noted in your question, but in general you'll need to create them yourself since they are often database-specific. Use the http://grails.org/plugin/database-migration plugin for this.
In general you will use indexes on columns that are part of frequent queries and queries with high execution cost. This will happen using any relational database and any development framework.
About Grails, I found this post very useful in how indexes are defined in Grails: http://grails.asia/grails-how-to-create-custom-table-index-or-composite-index
I plan on updating some table names by create a synonym of the old name and renaming the table to what I want it to be. Can replication properly reference a synonym?
Also as a side question, is there an easy way to see if a specific table is actually being replicated? (via a query perhaps)
I don't think so. Replication works by reading the log and there are no log records generated for a synonym. As to your question about finding out which tables are replicated, a query on sysarticles in the table should get you where you want to go. HTH.
I've just come across something disturbing, I was trying to implement transactional replication from a database whose design is not under our control . This replication was in order to perform reporting without taxing the system too much. Upon trying the replication only some of the tables went across.
On investigation tables were not selected to be replicated because they don't have a primary key, I thought this cannot be it is even shown as a primary key if I use ODBC and ms access but not in management studio. Also the queries are not ridiculously slow.
I tried inserting a duplicate record and it failed saying about a unique index(not a primary key). Seems to be the tables have been implemented using a unique index as oppose to a primary key. Why I do not know I could scream.
Is there anyway to perform transactional replication or an alternative, it needs to be live (last minute or two). The main db server is currently sql 2000 sp3a and the reporting server 2005.
The only thing I have currently thought of trying is setting the replication up as if it is another type of database. I believe replication to say oracle is possible would this force the use of say an ODBC driver like I assume access is using hence showing a primary key. I don't know if that is accurate out of my depth on this.
As MSDN states, it is not possible to create a transactional replication on tables without primary keys. You could use Merge replication (one way), that doesn't require a primary key, and it automatically creates a rowguid column if it doesn't exist:
Merge replication uses a globally
unique identifier (GUID) column to
identify each row during the merge
replication process. If a published
table does not have a uniqueidentifier
column with the ROWGUIDCOL property
and a unique index, replication adds
one. Ensure that any SELECT and INSERT
statements that reference published
tables use column lists. If a table is
no longer published and replication
added the column, the column is
removed; if the column already
existed, it is not removed.
Unfortunately, you will have a performance penalty if using merge replication.
If you need to use replication for reporting only, and you don't need the data to be exactly the same as on the publisher, then you could consider snapshot replication also