Actually I want to migrate a large dataset to another database which already has some data. Data Schema is same in Both DB. Scenario is that my client has application that already running in production and he had given me some new requirements to implement that. after implementation he want to test new requirements on temporary production server for acceptant testing on 2 Locations. So that I have attached existing database to new production server. Now I want to write a DB script that migrate data of location between before and after acceptance testing. My problem is that Ticket ID of my table has identity and running application on both data servers will insert same TicketIDs. Now when I migrate the data, there is a conflict of Primary Key. My schema of parent table is as follow.
TicketID, Identity(1,1) int
LocationID int
Problem varchar(500)
IssueDate DateTime
Another issue is that Ticket ID is print on Customer Receipt and client don't want to change Ticket No.
Please suggest me solutions of this problem.
One Solution is that to add a column OldTicketID but for that I need to change my application code and I don't want to change that there are many child table of that.
You can change the identity column to only generate odd numbers on the old dataset (identity(1,2)) and only even numbers on the new dataset (identity(seed,2)).
Seed should be set to the highest ticketid that's currently in the production system, so there wouldn't be any conflicts with the ids.
Related
It's my first time creating an audit log for a PoS WPF application and was wondering on how exactly do I implement an auditing system because it seems like each option available has its ups and downs. So far from reading numerous articles/threads, I've narrowed down a few common practices on audit logs:
1. Triggers - Unfortunately, due to the nature of my app, I can't make use of triggers as it has no way of knowing which user has done the action. So what I did instead was to create a Stored Procedure which will handle the customer insert along with the customer log insert and its details. The Customer_Id will be provided by the application when using the Stored Procedure.
2. Have an old and new value - My initial plan was to only include the latter since I can reference its old value with the new value from the row before it but storing the the old and new value seemed more sensible, complexity-wise.
3. Use a separate database for the log / 4. Foreign Keys - This is probably my main concern, if I decide to use a separate database for the audit table, then I couldn't setup foreign keys for the customer and employee involved.
I created a mock-up erd with a master-detail table result to be shown on the wpf app to display the log to an admin and would really like your thoughts on possible problems that may arise (There's also an employee table but I forgot to put it):
https://ibb.co/dheaNK
Here's a few info that might be of help:
The database will reside together with the wpf app, which is a single computer.
The amount of customers will be less than 1000.
The amount of regular employees will be 3.
The amount of admins will be 2.
You can enable CDC Change Data Capture on SQL Server database for a specific table
This will enable you to collect all data changes on the database table logged in special tables.
You can also refer to official documents too
Here is a list of DML commands and how data changes are logged in the CDC table created for the source database table
What is good about CDC is it comes default with SQL Server and you don't have to do anything for logging. The only requirement is SQL Server Agent should be running so that the changes can be reflected on log table.
I have taken over a project with an existing SQL server installation. The client wants to move everything to the azure SQL and make several on premises databases sync to azure.
The PK's in the tables are int's and for the Azure datasync to work PK's needs to be guid's. the database consists of several related tables.
My question is therefore. What is the best way to change the PK's to guids and at the same time update the FK's accordingly in existing tables.
The process as far as I see it:
1. Create new guid column
2. fill it with ID's.
3. change the PK to the guid column
4. update data to new guids in the FK tables.
Is there an easy scriptable way to make this magically happen?
No there is nothing built into SQL Server that makes this any easier than the process you described already.
I have an existing Azure web application backed by an Azure SQL db. My plan is to utilize this same db in new mobile applications I am building, however I made a design decision originally that doesn't work with Azure Mobile Services. I made my keys in the existing database integer ID's and as of recently to utilize a db within the Mobile service it needs ID's that are String GUID's. I have over 200 users entered in my existing database with other associated tables all tied to these ID's.
My question is, is there a feature or methodology for converting all of these integer keys to string keys without dropping all of their data and requiring everyone to manually go in and re set things up again?
My database knowledge is limited but from all I've seen, Azure Mobile Service requires that the keys be strings now and there isn't a work around for it.
Any help is much appreciated, Thanks!
To change the datatype of a column in SQL, just simply run the following command:
ALTER TABLE table_name
ALTER COLUMN column_name column_type
For example, assume your table name is table1 and the column is called keys,
ALTER TABLE table1
ALTER COLUMN keys varchar(10)
I am creating an application in Microsoft Access. This is for a small database that the customer will run on a desktop. No network of any kind will be involved. All the necessary files to use the database must be on a single desktop computer.
I want to deliver the app to my customer in stages. Most likely I will email the .accdb file to the customer. How do I deliver an update and maintain any data already entered by the customer? Updates may include changes to the table structure as well as to forms.
The answers given to my original question address the issue of changing forms and other UI elements. However, what if I want to add a table or add column to an existing one? How do I seamlessly deliver such changes while preserving as much data as possible on the user's end?
Split the database and the interface into separate files. Google should have plenty of information as this is typical for MS Access apps.
Here are a few resources to get you started:
How to manually split a Access database in Microsoft Access
Splitting an Access Database, Step by Step
You absolutely MUST (!) split your database into two parts. A backend part storing the tables ("the database") and a frontend containing the forms, reports, queries and application logic ("the application"). Link the tables from the backend to the fontend.
The frontend might also contain tables with control paramameters, report dictionaries etc., but no data that your customer enters!
Newer versions of Access have a database splitting wizard.
You might need a code that automatically links the backend to the fontend on the customers site.
UPDATE
You have two possibilities to alter the schema of your database on the customers PC.
1) Do the Updates through the DAO (or ADOX) object models. e.g.
Set tdf = db.CreateTableDef("tblNew")
tdf.Fields.Append tdf.CreateField("fieldname", dbText)
...
db.TableDefs.Append tdf
2) Use DDL queries
CREATE TABLE MyNewTable (
ID AUTOINCREMENT,
Textfield TEXT(50),
LongField LONG,
...,
CONSTRAINT PK_MyNewTable PRIMARY KEY (ID)
)
Or
ALTER TABLE SomeExistingTable ADD COLUMN Newcolumn Text(50)
We have an MS Access database that we want to migrate to a SQL Server Database with a new DB design. A part of the application that uses the SQL Server DB is already written.
I looked around to find out how to do the migration step most easily and started with Microsofts SQL Server Integration Services (SSIS). Now I have gotten to the point that I want to split a table vertically for normalization reasons.
A made up example looks like this
MS Access table person
ID
Name
Street
SQL Server table person
id
name
SQL Server table address
id
person_id
street
How can I complete this task best with SSIS? The id columns are identity (autoincrement) columns, so I cannot insert the old ID. How can I put the correct person_id foreign key in the address table?
There might even be a table which has to be broken up into three tables, where a row in table2 belongs to table1 and a row in table3 belongs to a row table2.
Is SSIS the appropriate means for this?
EDIT
Although this is a one-time migration, we need to have an automated and repeatable process, because the production database is under heavy usage and we are working on the migration in our development environment with recent, but not up-to-date data. We plan for one test run of the migration and have the customer review the behaviour. If everything is fine, we will go for the real migration.
Most of the given solutions include lots of manual steps and are thus not appropriate.
Use the execute SQL Task and write the statement yourself.
For the parent table do Select into table from table... then do the same for the rest as you progress. Make sure you set identity insert to ON for the parent table and reuse your old ID's. That will help you keep your data integrity.
For migrating your Access tables into SQL Server, use SSMA, not the Upsizing Wizard from Access.
You'll get a lot more tools at your disposal.
You can then break up your tables one by one from within SQL Server.
I'm not sure if there are any tools that can help you split your tables automatically, at least I couldn't find any, but it's not too difficult to do manually although how much work is required depends on how you used the original tables in your VBA code and forms in the first place.
A side note
Regarding normalization, don't go overboard with it: I know your example was just that but normalizing customer addresses is not always (rarely?) needed.
How many addresses can a person have?
If you count a home address, business address, delivery address, billing address, that's probably the most you'll ever need.
In that case, it's better to just keep them in the same table. Normalizing that data will just require more work to recombine and offers no benefit.
Of course, there are cases where it would make sense to normalise but I've seen people going overboard with the notion (I've been guilty of it as well) and then find themselves struggling to build more complex queries to join all that split data, making development and maintenance harder and often suffering a performance penalty in the process.
Access is so user-friendly, why not normalize your tables in Access, and then upsize the finished structure from there?
I found a different solution which was not mentioned yet and allows us to use all the comfort and options of the dataflow task:
If the destination database is on a local SQL Server, you can use a dataflow task with SQL Server destination instead of an OLE DB destination.
For a SQL Server destination you can mark the "keep identities" option. (I do not know if the english names are correct, because we have a german version.) With this you can write into identity columns
We found that we cannot use the old primary keys everywhere, because we have some tables that take a union of records from multiple tables.
We start the process by building a temporary mapping table with columns
new_id (identity)
old_id (int)
old_tablename (string)
We first fill in all the old_id s for every table that is referenced by a foreign key in the new schema. The new_id values are generated automatically by SQL Server.
So we can use a join to translate from old_id to new_id where needed. We use the new_id values to fill the identity (primary key) columns in the new tables with the "keep identities" option and can simply look them up in our mapping table for the foreign keys by a join.
You might also look at Jamie Thomson's SSIS Normalizer component. I just found out about it today (haven't actually tried it yet). The example he posts looks a lot like the one in your question.