OK, I'm warming up to Git and DropBox for version control. I'm creating DNN sites and I'm in the process of using Git/DropBox.
I would also like to use Git on the SQL Server backing database.
Is there some sort of best practice that could be employed here?
I'm currently getting an access denied error when I attempt to create a repository in the SQL Server DATA directory.
You probably don't have permissions to make a .git folder in there. I would use the sql server tools to create the backup files elsewhere. I would then back those up. You should have no problem putting those in a git repo.
Hope this helps.
I set my database file location to a custom directory, then stopped the database service and added read/full rights for all users in the system to the file. After that, git had no problem adding the file to version control.
Related
I am trying to link by database to Redgate Source Control but I am getting the error.
I have repository in SVN Source Control system in local folder.
Version of Redgate Source Control: 7.0.6.8775
SVN version: TortoiseSVN 1.11.0
Following is the error message.
Unable to connect to a repository at URL 'file:///D:/SVNRepo/DevDB'
Screenshot: https://www.screencast.com/t/2pPpZbR1
Anybody know how to fix?
I solve it, it was version issue.
I created the repository in TortoiseSVN 1.9.4 and it works.
If you want to connect it to a local folder, then you must tell it to connect to Working folder from the left pane. You told it to connect to SVN, but giving it a path to a folder. Click the radio button next to Working folder and browse to the folder where your working copy is stored, or where you want to make one.
I have a Windows server with MS SQL Server running on it.
On the SQL Server developers have created stored procedures, views, tables, triggers.
On the Windows server developers created shell scripts.
I would like to start versioning the code described above in a BitBucket repository. I have a repository created in BitBucket.
How should the branches be organized in this repository? i.e. "SQL Server\Database\\ ...
"Windows Server\\shell_script" ...
Can I connect BitBucket to SQL Server and Windows Server and specify which code needs to be versioned?
Are both 1 and 2 options above possible?
I just need to version control the changes to the code and have the ability to mark under which project the code change was made.
I am new to BitBucket. I am using the web front end of it. I do not know how to configure command line access, so please try not to reference Bitbucket commands. Sorry if I sound confusing.
Please help.
I know this is an old question but anyway, in principle I'd recommend:
Put all the server shell scripts into one place and make that a git repo linked to your bitbucket repo
Add a server shell script to export what you want version controlled from the SQL db
The export from the SQL db should be to text files so they are easily 'diffable'
You might as well make the export to a sub-directory within the shell scripts repo so that everything is in one place and can't get out of sync
So you only have one branch, not a separate one for server shell scripts and db
Make sure people run the export script and then commit everything when they make a change
You ideally have a test server which means you'd want a way to push changes from the repo into the SQL db. I presume you can do this with a script but deleting the server setup and re-creating it from the text files.
So basically, you can't connect an SQL db to bitbucket directly. You need scripts to read and write to the db from a repo.
I'm a newbie to pushing Drupal websites from local to live via a CP panel with a hosting company and wondered if there are any key steps I need to follow? I usually end up with Internal Server 500 errors or no themes showing so not a good start!
The steps I follow are:
Export the database from my local PHPMyAdmin
Log into my hosting CP Panel and create the database on there
Create a user for the database (with password)
Change the settings.php to match the database settings
Load all Drupal files via FTP
Create a 'tmp' folder in the 'sites > default> files' directory
What am I doing wrong?! Is it something to do with the .htaccess file as to why I either get the error or my theme never shows?
Any help would be much appreciated! So stressful and frsutrating as a newbie! Once I've done 1 I'm hoping it'll be plain sailing!!
Thanks!
C
You have the basic steps right. Check the php error logs on the server (probably accessible via the control panel if you dont have ssh access), they should give you more information as to what actually caused the 500 errors.
Doubt it is an htaccess issue unless you are doing something crazy in there.
Can you see he drupal admin at all? If so, clear cache, check watchdog for clues also.
It's easier to download and install Drupal again on the live server rather than to copy everything via FTP. The settings.php file is where your MySQL information is stored so this file should not be copied. Follow Drupal's documentation on how to install Drupal at https://drupal.org/documentation/install/download
To transfer your database, install and enable the Backup and Migrate module on your local server from https://drupal.org/project/backup_migrate and back up your database locally.
After Drupal is installed on the live server, go ahead and copy your modules, themes, and files from /sites/all and /sites/default/files (or any non-Drupal core files that you may have created). Enable and use the Backup and Migrate module to restore your database to your live server. You may need to configure the php.ini file if the database is over 8MB.
I have a simple WPF application that uses ClickOnce to handle installing. Within this application is a compact database. Through testing I have found that when I publish a new build this database will get overwritten, which is not what I want. Is there anyway I can have fine grained control over what files are updated? I assume ClickOnce is simply checking the hash of the database file, deciding that it has changed and pulling the update.
As a workaround I have since removed the database from the files that are included with the published application so the original remains on the client machine after an update, untouched.
Not a great solution I know
Thanks,
ClickOnce deployments segregate the Application Files into "Include" or "Data file". You can specify what each file is in visual Studio by going to the project Properties page, Publish tab, then clicking the "Application Files..." button. You can then set your .sdf file to "Data File" under the Publish Status column.
Data Files that are downloaded with a ClickOnce application are then placed in a separate directory for each new version.
The idea is that on the first run of the new application version, you go retrieve all the user's private data from their old-version data files and incorporate that data into the new data files which have just been downloaded with your new version.
I think you'll find the information you need at Accessing Local and Remote Data in ClickOnce Applications. Specifically, look at the sections "ClickOnce Data Directory" and "Data Directory and Application Versions."
To access a SQL Server CE database located in your Data directory, use a connection string similar to the following:
<add
name="MyApplication.Properties.Settings.LocalCacheConnectionString"
connectionString="Data Source=|DataDirectory|\LocalCache.sdf"
providerName="Microsoft.SqlServerCe.Client.3.5" />
The "|DataDirectory|" is a special syntax supported by SQL CE and SQL Express and resolves at runtime to the proper directory.
If you so much as open that SQLCE database included in your project, it will change the time stamp on the database, and ClickOnce will deploy it and put the old version under the \pre subfolder.
You might want to consider this method for handling this. Then if you accidentally deploy a new version of the database and don't realize it, you're not hosed. If you intentionally make changes, you can change the database structure of your current database with SQL queries, and pull data from the new copy deployed to the Data Directory (that you're otherwise ignoring) when you need to.
RobinDotNet
I'm using the Database Publishing Wizard in VS2008 to push changes to my hosting provider. It doesn't look like those settings go with the project (which seems a little silly to me), but rather they go with the machine.
On each new machine that I'd like to publish from I need to go through the process of digging up my database settings.
Is there a way to backup/export/save these settings to a file?
If so, what is it?
Hmmm ... it appears that the publishing wizard uses 2 config files for it's application configuration:
The Publish Database Wizard uses the
files user.config and hoster.config to
store configuration information. The
directory in which these files are
stored must have the appropriate NTFS
file system permissions set. These
files contain user names and encrypted
passwords. The passwords are encrypted
by using DPAPI.
user.config File
This file stores persisted host and
configuration settings for the Publish
Database Wizard. The user.config file
is located at %SystemDrive%\Documents
and Settings\%Username%\Application
Data\Microsoft\Microsoft SQL
Server\90\Tools\Publishing
Wizard\user.config.
hoster.config File
This file stores options about Web
service addresses, user names, and
databases for shared hosting
providers. The hoster.config file is
located at %SystemDrive%\Documents and
Settings\%Username%\Application
Data\Microsoft\Microsoft SQL
Server\90\Tools\Publishing
Wizard\hoster.config.
I'm trying to access these files in Vista (with VS2008 and SQL Express installed) and striking out. I'll keep you posted.
Update: Looks like I didn't have the Publishing Wizard installed after all. After grabbing the version for VS2008 here, and then installing (and don't worry -- you won't see any indication it's getting installed, but it does).... and THEN setting up my first database using the wizard, it looks like there are indeed some settings stored uder the 'Application Data' directory listed above. However, it looks like it's just a user.config, and then an XML file for each database configured. I believe you can backup each of these files for later use.