I've just been studying DBMS. There are a lot of programs for DB. (eg. Mysql, MariaDB etc..)
So I wonder in program, for example Postgresql, can I change data structure each table?
Most of programs are using B-tree, however I hope change data structure each table if I can.
Are you asking if you can change the table structure like adding or removing columns, altering the data type of a column, if yes, then it is possible.
Refer here for postgresql syntax
Refer here for SQL Server/MS SQL syntax
Refer here for MySQL syntax
Related
I am creating database snapshot for reporting(creating a common demoralized table from normalized tables), for which I need to enter normalized tables modified values at the same time when the table modify. I want a common solution for this. Same is achievable using triggers but I am looking for some other generic solution which will work with any table change. Is there any other way in SQL server by which I can achieve the same?
I am very new to SQL, MS Access & PostgreSQL. So this might be a very silly question but somehow I can't figure it out. I'm trying to run SQL queries in access and my data is in a PostgreSQL database table which was linked to access by my colleague earlier. When I make this simple query why do I get an error that the table doesn't exist? Is the syntax different for linked database tables? Or is the link not yet established?
You have created a Pass-Through query. This query is executed on the server, not in Access, so you need to use the original table names from the PostgreSQL database.
So it's not FROM public_tb_change but FROM tb_change.
Or maybe FROM public.tb_change, if public isn't the default schema.
I advise to rename your linked tables to the original name (remove public_), that makes things much less confusing. The schema name is automatically added by Access when linking the tables.
I need to export/update schema without loosing existing data. I found that there are two Red Gate tools which you are probably have heard about:
SQL Compare;
SQL Data Compare;
Which one of them could help me to solve migration?
You need SQL Data Compare, because SQL Compare is only synchronizes the schema not the data.
It depends on the nature of the change. SQL Compare will preserve your data when it makes a schema change, even if a change that requires a table rebuild.
However, if you make a change such as a table rename, or a table/column split, SQL Compare won't understand the 'intent' and may produce a script that isn't as you would expect.
The solution to that would be to use SQL Compare in conjunction with SQL Source Control and its migration scripts feature, which makes it highly customizable.
SQL Compare would be sufficient, If the warning is a result of a table rename, you can simply use the table mapping tab in the 'project settings' to tell SQL compare that they are the same table.
P.S. I know this post is ancient, but it's best to use the right tool :)
I had a notion to use a database column of type replication ID, but have since changed my approach and want to use this column for another purpose.
However, I'm unable to use SQL to drop the column to remove it from my database.
My SQL is:
ALTER TABLE foo_bar DROP COLUMN theFoo;
However, I get a "syntax error" and I'm assuming this has something to do with this column being a replication ID.
I'd rather not download the file and edit it directly using the MS Access application, but not sure if that's my only recourse.
Thanks so much in advance.
Regards,
Kris
If you have access to the database in a command shell, Michael Kaplan's Replication System Removal Fields utility should do the trick. However, I've found that in some circumstances, it's unable to do the job. Also note that the utility will only work with a Jet 4 format database (MDB), not ACE format (ACCDB).
If all else fails, you can recreate the table structure and append the existing data to it. That can get messy if you have referential integrity defined, though, but it will get the job done, and likely most of it is scriptable (if not all possible using just DDL).
Here is a link that may help you, I had a similar idea but when browsing the web found this
AccessMonster - Replication-ID-Field-size
EDIT: Well I don't have much time but what I was thinking of first was if you could alter the column to make it different (not a replication ID) and then drop it. (two separate actions). But I have not tested this.
I would like to copy parts of an Oracle DB to a SQL Server DB. I need to move the data because the Oracle box is being decommissioned. I only need the data for reference purposes so don't need indexes or stored procedures or contstaints, etc. All I need is the data.
I have a link to the Oracle DB in SQL Server. I have tested the following query, which seemed to work just fine:
select
*
into
NewTableName
from
linkedserver.OracleTable
I was wondering if there are any potential issues with using this approach?
Using SSIS (sql integration services) may be a good alternative especially if your table names are the same on both servers. Use the import wizard via and it should create the destination tables for you and let you edit any mappings.
The only issue I see with that is you will need to execute that of course for each and every table you need. Glad you are decommissioning the oracle server :-). Otherwise if you are not concerned with indexes or any of the existing sprocs I don't see any issue in what you are doing.
The "select " approach could be very slow if tables are large. Consider writing pro*C in that case or use Fastreader http://www.wisdomforce.com/products-FastReader.html
A faster and easier approach might be to use the Data Transformation Services, depending on the number of objects you're trying to copy over.