I would like to drop one column in existing table. When I simply remove it from table's create script it will cause error (data loss...) on deployment. I would like to allow (in this case) column drop. How you would do that?
To disable the data loss error:
Click the Options icon in your schema comparison file.
Uncheck "Block on possible data loss".
The setting will change for just that 1 schema comparison and it will be saved within the schema comparison file. If you only want to do this once then you'll need to re-enable the option after you drop the column.
We did this by creating a PreDeployment script to drop the column. Reasoning is we do not want to allow data loss for all objects in the database.
You can create automated version checks to do this only once (see my answer to another post Nontrivial incremental change deployment with Visual Studio database projects for steps how to automate this with SSDT.)
Or you can just supply the script to devops and include instructions in your install manual to run it once for a specific release.
After the release has gone live, you can delete the PreDeployment script.
Related
We are working on Joomla3.9 project, have different environments and are using git as vcs. So every developer works on is own branch. It would be nice to have a database compare function like in TYPO3 or Contao (see the database differences after updating the project and apply the database changes just by one click). Or like the laravel migration system.
Any developer should easily update his own lokal database after database changes where made due an extension update via backend or by another developer. And of course the staging or live system must be updated easily too. We don't want to execute sql-scripts with the changes in phpMyAdmin.
We have tried https://dbv.vizuina.com/ . This is not the 100% solution. Like there is no cli support to start the migration process by an update script on the server.
Does anyone have a solution or knows an extension that can solve this problem? Or can this be handled with core Joomla functions (maybe with a little adjustment)?
So far, I've seen three possibilities to execute modifications to one ore many extension tables
1: Use the extension - revision control in the schema table. So add a new sql-file with an increased version number compared to the version number in the schema-table for this extension. Increase also the version in the manifest.xml and zip the extension again.
Reinstall the extension via extension->manage->install. So the new sql-file with the increased version number will be executed.
2: like the point above, but install the extension via joomla update mechanism (update server).
3.: create a new sql-file in sql/folder of the extension. No version name is needed for the new file, just update.sql oder another filename. Execute this script in script.php in update()-method, after the extension is installed (in this case it's an update) again.
The third possibility might be interesting. It should be possible to trigger the update()-method with a cli command / function, so that the method can be triggered via a script on the server.
But how can I get the info, which update-scripts have already been executed? Let's say I have 3 update files in sql-folder. update-1.sql, update-2.sql and update-3.sql.
update-1.sql has already been executed. So I don't want to execute this sql-file again - only the other two.
The schema-table is only used with the first two options. Do I have the info somewhere or must I manage the infos which update-scripts have been executed myself?
The answer related to versioning database for extensions depends on whether these extensions are tightly coupled to the application or need to be reusable to other applications also.
The latter case normally means that each extension accesses its own custom tables, in which case you should keep separate versioning for the database than for the extensions.
App version history can be kept in a db_version table. Then an insert statement is added at the end of each update script (adding an incremental version number). e.g.
insert into db_version(version,author,description) values(003,'Verna.Collins', 'removing obsolete column');
Provided that you need to apply data migration on extensions also, you need to maintain a db_version_extensions table which keeps version history for each of the extensions separately. e.g.
'001' 'extension1','Mandy.Aguilar','initial version'
'002' 'extension1','Mandy.Aguilar','adding extra column'
'001' 'extension2','Edna.Potter','initial version'
'002' 'extension2','Elvira.Townsend','dropping unused table'
..etc
Each extension zip should keep initial creation script and all sql-update files(which should normally not interfere with the rest of the app tables).
After pull it will be relatively easy to execute all the scripts with filename version greater than the last version number written in the database. This should be done for the app and for each extension separately.
Now if the extensions are tightly coupled to the app, it means that they might be using/updating tables of the app. For extensions of this type, you can add the updates as part of the application updates. These extensions could even be developed at the same repo, and be kept as directories instead of zip files.
Not sure if joomla supports any tools for automating the process of performing incremental db updates, but a nice tool is flyway, with ports for command-line, maven and graddle. See: how does flyway work
I'm using Visual Studio Pro 2013 and want to use the Fuzzy Lookup task but there seems to be a bug that prevents the component from connecting to the reference tables.
A reference file and table is specified in the Connection tab which all seems fine but the Columns tab is also needed to create the reference links between different fields of the data however there is nothing there:
The error messages are as follows:
I've read elsewhere this was a known bug on older versions of SSIS from about 2005 - anyone know what the problem is here and how I can fix this?
I should add that the connection manager and the table seem fine as they have been used many times elsewhere in the project. I've tried recreating the data flow in a new document and even restarting my PC but this simply won't work. I should add that I've not used the Fuzzy Lookup before but have looked at several references and know that the column tab should be populated with data and not be an issue.
Many Thanks,
Kw
Not a bug, it's how the product works. From the manual, it specifies the reference table must be a table in sql server. A table in Access, therefore, is unsuitable for use in the fuzzy lookup component.
The transformation needs access to a reference data source that contains the values that are used to clean and extend the input data. The reference data source must be a table in a SQL Server database
I'm working on creating a deploy script to migrate new development from our dev server to our uat server. Unfortunately, the devs that made the changes didn't script them out at they coded. The easiest way for me to approach this is to use SqlDeveloper's database diff functionality. It does a good job of highlighting the differences and creating a script that I can run on UAT. However, I've noticed that it doesn't take into account any dependencies. For example, a it will put a command to create a table below a table that references it in a foreign key constraint. Because the referenced table doesn't exist yet, the first table create command fails. I've seen this with views referencing packages, packages referencing packages, etc. Is there any easy to way either 1) force sql to export in a "smarter" order or 2) manually calculate the dependencies (ex: querying USER_DEPENDENCIES, etc) so that i can manually sort the file of create commands without resorting to trial and error? I guess we could consider purchasing a commercial product as long as it matched exactly what we are looking for.
Note: we will probably have to deploy to UAT multiple times in order to support testing by end-users. I am trying to automate this as much as possible so I don't have to manually recreate this script every single time!
Thanks!
I have a database that is created by the WIX installer using SqlScript and SqlString tags. Inside the database is a table "AppVersion" with a field "VersionNumber".
I can create the database just fine, but I'm working on the upgrade script now. How can I make my upgrade MSI check the value of the AppVersion.VersionNumber field as a condition of upgrading?
I see tags to check registry values, but nothing so far on how to check database values as a condition.
Thanks in advance.
EDIT Oh yeah, saving the value in the registry is not viable because the databases are backed up / restored to different machines often enough that the installer itself must use the database version field.
Generally I put all of that logic into SQL. A script should be smart enough to create a table only if it doesn't already exist and to alter a table only if it needs to. It's not the job of the installer to do all that logic and then decide which SQL scripts to run.
first question ever on this site.
I've been having a real stubborn problem using Visual Studio 2008 and I'm hoping someone has figured this out before.
I have 2 libraries and 1 project that use strongly typed datasets (MSSQL backend) that I generated using the "Configure DataSet with Wizard" option on in Data Sources. I've had them working just fine for awhile and I've written a lot of code in the non-designer file for the row classes. I've also specified a lot of custom queries using the dataset designer. This is all work I can't afford to loose.
I've recently made some changes to re-organize my libraries which included changing the names of the libraries themselves. I also changed the connection string to point to a different database which is a development copy (same exact schema).
Problem is now when I open up "Configure DataSet with Wizard" to pickup a new column I've added to one of the tables it no longer matches the tables correctly in the wizard. The wizard displays all of the tables in the database and none of them have check boxes next to them (ie: are not part of this dataset). Below those it shows all of the tables again but with red Xs and these are checked. Basically meaning that Visual Studio sees all of the tables it currently has in the DataSet and sees all of the tables in the database, but believes they are no longer the same and thus do not match!
I've had this same thing happen quite awhile back and I think I just re-built the xsd from scratch and manually copied the code over and then had to redefine all of the custom queries I built in the dataset designer. That's not a good solution.
I'm looking for 2 answers:
1. What causes this to happen and how to prevent it.
2. How do I fix this so that the wizard once again believes the tables in its xsd are the same tables that are in the database (yes, they have the exact same names still).
Thanks.
The dataset designer uses the default query (The first one with a check on it) to sync up the schema for each table. Whenever you go to edit the default query, VS will actually connect to your datasource and look for changes in the query. If new columns are added, they will show up as new columns for you to add to your table. Renamed columns show up as new, since VS doesn't have any way to know that you changed the name.
Answer 1. The XSD file contains the names of the database tables that it used to create the table originally. If you change the name of the table, the designer won't know which table to sync to.
Answer 2. You can edit the XML inside the XSD file. Do a "Find and Replace" inside the XSD file replacing the old tablename for the new tablename. Make sure you have a backup of the XSD file before you do. Be careful to only change instances of the old table name and not any other working XML.