We have big database with a lot of stuff and I want to use version control (Git) to manage changes.
There are a lot of articles how to do it step by step but one piece is missing for me.
Is there standard or recommended way for file structure of whole database (data excluded) and how it can be obtained from existing database?
It is a lot of sources, procedures, functions, packages, etc.
Version control articles show how to manage few files from version control perspective. But they suggest that each file should be selected and saved to file system separately.
Is there way to export/import all stuff to maybe some preorganized structure?
Good IDEs have such structures defined by languages or products. But it looks for me that SQL Developer doesn't have one.
It also looks for me that SQL Developer may have only one repository. No concept of projects which can combine or unite different databases in separate units.
Should I invent my whole structure and use something like
**project/Abc/DB1/Packages/packzgeXyz/source1.sql**
for each source? Sure I can do this but I worry that may miss something.
Any advise?
Yes, SQL Developer can unload a schema to files for you. And then you could take such files to your SVN or Git projects.
Tools - Database Export.
I set the output to multiple directories - so one directory for schema object type.
Then I set my application schema, then proceed to FINISH/OK.
Output looks like:
I talk about this in more detail here.
Related
Since Access 2013 is not any longer offering direct source control compatibility: how is your workflow to integrate a source code control into MS Access, especially TFS?
Edit: workflow of access2013 -> ANY source code system appreciated
First thing I think of is exporting all objects into Text Files withe the builtin function SaveAsText which is available for almost every item in your database.
Application.SaveAsText acModule, d.Name, sExportLocation & "Module_" & d.Name & ".txt"
I would load, save and maybe even check the plain files in with VBA functions. The question is: is there a better workflow for this task... I really doubt that this is the best way to integrate Access 2013 projects in Sorce control.
I heard of OASIS SVN but I think this is basically the same mechanism I would use.
Please tell me how you manage your access projects
I use OASIS-SVN here to export all objects in my access database file to be text files.
I then use git, souretree, etc...
It has worked well for me and has a number of settings that are useful (eg you can choose to export data, to export table links etc)
It is not ideal, but is manageable and better than nothing!
As you might expect, I use a git project and separate local directory for every access file.
Another option that is recently on the market can be found here "entAscc" now known as Ivercy!
This looks very promising as the source control is integrated into the development environment. I've not used it, but would like to!
Trying to determine if there is any behavior analogous to SVN:Externals in IBM Rational Synergy CM.
Ultimate objective is to find a more integrated way for Synergy projects existing in one database to contain files originating from another database without manually copying them to the second database and manually propagating changes. SVN of course supports this through the concept of Externals which allow you point to directories or files even on a different repository.
Search has revealed nothing so far, and unfortunately use of Synergy is mandated in this situation so switching revision control tools is not an option. If manual copying is the answer, so be it, just wanted to confirm.
The only way to share projects and files between databases is the DCM concept (see manual) . However, it's quite complicated to use and require some scripting in order to function properly. If you have simple needs you can always do it "outside" Synergy with a simple file/directory repository.
Situation:
I need several swf/exe output files compiled in FlashDevelop from several projects. More than 60% of ActionScript 3.0 source is common for all project, rest are project-specific. How can I organize that in FlashDevelop? I want to have "one-click-to-build all" setting without duplicating common codebase (so when I need to fix something I do not need to copy-paste solution into several files).
All sources are under develeopment and will change very often.
A straightforward solution is to make an external classpath, for instance:
c:\dev\shared_src\
c:\dev\project1\
c:\dev\project2\
Then configure each project:
Project Properties > Classpath
Add Classpath > select '../shared_src'
PS: of course you should keep everything under source control.
Using svn:externals you could structure your repository in such a way that the commom parts are stored just once in the source control system, so changes made can be synchronised with just a single commit and update cycle.
For example, imagine that you have ^/ProjectA and ^/ProjectB, each of with require ^/Common as a sub directory.
Using svn:externals, pull ^/Common into both projects.
The exact nature of doing this will depend on the version of svn you use, and any client you use (such as TortoiseSvn). Refer to the relevant edition of the svn book for specifics.
The ease of implementing this will depend quite a lot on how separate the common code currently is in your application; and pulling in directories as directories is much more practical than trying to pull them into an existing directory; and unfortunately wildcards for filepaths are not supported.
However, based on your description of your aim; this is the most straight-forward solution I can imagine.
Hope this helps.
Currently I go into phpMyAdmin, export my database as a text file and then save it with the application files before I commit things to svn (or git). Then of course, I've got to import it to production.
Is there a better way?
Depends on the language you use, RoR has it built in. Currently for a project I'm doing in ASP.net MVC I have 2 files in the project in a folder: database. One file contains the structure of the database and one file some dummy variables for testing. I must say it is a cumbersome way of sharing your database since when you update something you have to let the others know they have to rerun the (updated) sql structure script.
The structure script deletes tables if the exist and readds them + adds new tables.
Could not find a better way like db::migrate of Ruby on Rails.
If you don't have something like rails migrate, are in java environment or anything else, check out liquibase. It's pretty cool if you need that much flexibility. We just track .sql files which setup the entire database.
Generally, I would create a script that is able to generate the database (i.e., all the tables, users, views, indexes, etc) and another script that populates the DB with data. Then, use DBDeploy (similar to RoRs migrations) to handle all DB modifications. Then I would create build targets for all these script in Ant, NAnt, Buildr, etc. This way everything is versioned and in text files so it works with any SCM.
If you're looking for migrations similar to db:migrate in Rails, but you're not in rails, there are other options. There's migrate4j which is similar to db:migrate, but written in/for Java. There's also liquibase, which is very flexible and (AFAIK) language independent, but does make you write everything in XML (which is kind of the opposite of "the Rails way").
If you look at Apache ODE, they have a h2.rake task for Buildr that builds a database for testing automatically.
I do alot of bugfixing and implementing new features for several different customers. These customers all report their bugs, change requests and new feature request into our Trac system.
Sometimes these requests result in me creating some SQL change scripts, sometimes there are Excel documents or Access databases with testdata, Word documents from the customer and so on. Alot of files that are used to fix one ticket and then can be deletede when the ticket is closed.
I usualy do this by creating folders in the filesystem like this: /customerXX/TicketNNNNN and then just dumping everything in there.
How do you organize your workfiles? Have you found some fantastic tool to do this?
I would say for scripts or files that are related to a particular ticket, the best thing to do would be to attach the file to that ticket in your issue tracking software - almost all issue trackers that I've worked with will allow you to do this. That way, you can look back and a) see exactly what you did in case something goes wrong, or b) do exactly the same thing if the issue comes up again later. That's almost certainly the best place to keep files with extra info from the customer, too (or at least the first place most people will look).
For frequently re-used scripts that aren't specific to a particular ticket, I would create a scripts/ or bin/ directory in the associated project, and keep them in there.
I also have a small handful of useful files that I keep in src/misc/ off my home directory, with things like SQL queries to get readable "explain" output out of Oracle and such, that aren't specific to any particular project. The number of these is small enough that subdirectories aren't necessary, though - I suspect if you ended up with a large number of these files, many of them could/should be moved to specific projects or your issue tracking system.
JIRA has been quite helpful for this at my site. It supports issue tracking, file attachments,and you can easily customize and categorize your projects and issues.
I use Fogbugz and I add all file to the case. I believe that no matter what application you use, The important is to keep this files for future references. If your bug-tracking tool does not let you attach file then add the files to the version control.
We use CaWeb4 and find it very easy to use for our bug tracking.