Is it possible to store Subversion meta data in SQL Server? We want a SQL Server based Subversion.
There isn't anyway to do that right now. Subversion lets you choose between FSFS and Berkeley DB, with FSFS being the better choice for most people. (Berkeley DB has some issues around getting corrupt).
Is there a reason you want to store the data in SQL Server?
I with James Avery - why do you want to store the data in an SQL Server? If you're wanting someway to interface with the underlying subversion data from a .NET library, check out SharpSVN: http://sharpsvn.open.collab.net/.
Subversion used to have BDB (Berkley Database) as its core storage. Most people moved away from that because it was hard to back up and corruption sometimes became an issue. I wouldn't recommend it but I am sure you could go look at the BDB code and have it hook up to a SQL Server.
Why use a backing store that you can so easily corrupt? Sure, you can corrupt the filesystem store, but most people have enough sense not to touch it.
As it is, future versions of SVN are looking to store revprop data in a sqlite db instead of files. If they do, then you should be able to access that in much the same way, but for the mutable revprops only. I'm not sure if they intend to restrict access to it to the svn libraries of allow any other process to read and write to it.
Of course, the biggest reason SQL server is not suitable for subversion is that it would completely break its ability to be cross-platform.
Related
I've never done databases before but I know that you can create them on MySQL, the thing is that I want to be able to write/read a database locally and not have to send/receive any information online as it would be too slow for what I need.
Is there a way to create a stand alone database (possibly on MySQL then downloading it) and write/read from it using LUA?
Thanks for any information, as I say, never touched databases.
Yes it is.
You can download sqlite3, which is a simple SQL relational DB. Basically this type of DB is just a file (.db extension), so you can have it locally on you PC and also exchange it between many machines easily.
From a Lua standpoint, what you need is a library to access your DB and I think LuaSQLIte3 is the best option to go with. Check this SO post for a basic example on this.
IMO using lua in conjunction with sqlite3 is one of the best choices when one wants to have a (light) SQL-based DB locally, without the added "complexity" of a more commercially used DB (e.g.postgres).
My question is this: Are there alternatives to ODBC that would allow us to connect our SQL Server to MS Access?
Here's the situation: My company works with a proprietary, SQL database (ProVenue) that up and decided to "no longer support ODBC" to MS Access, our front-end tool, without telling us.
We are currently migrating away from ProVenue, but in the meantime , we're stuck with a vendor, which "no longer supports" our ODBC connection(s). The vendor also has no incentive to help since we're leaving in several months.
I've devised a workaround where I manually export the ProVenue tables (ASCII), proof (yes, the export utiliy pulls unreliably), convert and upload on a daily basis into Access. That said, it is unreasonably time consuming given the number of tables. This work-around could be a full-time job.
Do you know of any alternatives?
Do NOT consider using ADP. It has been dropped from Access 2013 and hence is a technology with no future.
From what you're saying, you don't "own" your own MSSQL database - you're simply connecting to an instance that the provider manages, correct? I would guess that they've disabled ODBC connections to MSSQL because they don't like the load placed on their servers and/or that they've decided they want to change some underlying structures and don't want to have to cope with anybody whining about those changes.
That said, do they allow direct MSSQL connections? Via SQL Management Studio, for example? If so, you should be able to define an export & import process which is less buggy than theirs, and simply re-point your Access database to the local copy of data. True, this would still require some (possibly automated) import process, so you'd be out of synch with the server, but it'd give you the solution.
You might try connecting an .adp file to the server, to see if they'll still let you access things in that manner. That would possibly require significant modifications to your Access solution, but would also be a bit easier on their servers than linked tables via ODBC.
You could have a look at Access Data Projects (ADP) which are tied directly to one SQL Server database. I don't think they use ODBC at all, but they have their own limitations, and of course, aren't available in older Access versions.
well for example you have build a program, for restaurant, for a cinema, wherever,
now how do you do when, you install your application, the database was installed correctly too? i dont sure but i believe this is a different database? for example a file?
(talking about sql).
and how different are going to be the queries? cuz i believe i am not going to have the same function on sql server than a file database
and what connection i shall use?
could i use entity framework?
and how capacity could to have the different file for databases?
regards
You can use a file-based database like SQLite that supports SQL queries. There are ADO adapters available as well. The link should take care of the rest of your questions as well.
Well, since you usually have absolutely no knowledge about target environment, user must configure program to his envronment at install time, or later (af first launch for example, this is much simplier than implement same functionality in installer). User specifies SQL server address (if we are talking about server-based systems) and database name he wants to use. Then database is created programmaticaly using that information.
I am using github for maintaining versions and code synchronization.
We are team of two and we are located at different places.
How can we make sure that our databases are synchronized.
Update:--
I am rails developer. But these days i m working on drupal projects (where database is the center of variations). So i want to make sure that team must have a synchronized database. Also the values in various tables.
I need something which keep our data values synchronized.
Centralized database is a good solution. But things get disturbed when someone works offline
if you use visual studio then you can script your database tables, views, stored procedures and functions as .sql files from a database solution and then check those into version control as well - its what i currently do at my workplace
In you dont use visual studio then you can still script your sql as .sql files [but with more work] and then version control them as necessary
Have a look at Red Gate SQL Source Control - http://www.red-gate.com/products/SQL_Source_Control/
To be honest I've never used it, but their other software is fantastic. And if all you want to do is keep the DB schema in sync (rather than full source control) then I have used their SQL Compare product very succesfully in the past.
(ps. I don't work for them!)
You can use Sql Source Control together with Sql Data Compare to source control both: schema and data. Here is an article from redgate: Source controlling data.
These are some of the possibilities.
Using the same database. Set-up a central database where everybody can connect to. This way you are sure everybody uses the same database all the time.
After every change, export the database and commit it to the VCS. This option requires discipline and manual labor.
Use some kind of other definition of the schema. For example, Doctrine for php has the ability to build the database from a yaml definition which can be stored in the vcs. This can be easier automated then point 2.
Use some other software/script which updates the database.
I feel your pain. I had terrible trouble getting SQL Server to play nice with SVN. In the end I opted for a shared database solution. Every day I run an extensive script to backup all our schema definitions (specifically stored procedures) for version control into text files. Due to the limited number of changes this works well.
I now use this technique for our major project and personal projects too. The only negative is that it relies on being connected all the time. The other answers suggest that full database versioning is very time consuming and I tend to agree. For "live" upgrades we use the Red Gate tools, they do both schema and data compare and it works very well.
http://www.red-gate.com/products/SQL_Data_Compare/. We were using this tool for keeping databases in sync in our company. Later we had some specific demands so we had to write our own code for synchronization. Depends how complex is you database and how much changes is happening. It is much simpler if you have time when no one is working and you can lock database for syncronization.
Check out OffScale DataGrove.
This product tracks changes to the entire DB - schema and data. You can tag versions in any point in time, and return to older states of the DB with a simple command. It also allows you to create virtual, separate, copies of the same database so each team member can have his own separate DB. All the virtual copies are tracked into the same repository so it's super-easy to revert your DB to someone else's version (you simply check-out their version, just like you do with your source control). This means all your DBs can always be synchronized.
Regarding a centralized DB - just like you don't want to work on the same source code, you don't want to be working on the same DB. It means you'll constantly break each other's code and builds each time someone changes something in the DB.
I suggest that you go with a separate DB for each developer, and sync them using DataGrove.
Disclaimer - I work at OffScale :-)
Try Wizardby. This is my personal project, but I've used it in my several previous jobs with great deal of success.
Basically, it's a tool which lets you specify all changes to your database schema in a database-independent manner and then apply these changes to all your databases.
Scenario
i want to take backup from 7 client database to 1 server database.
i dont know structure of the db { either server or client db }.
both databases are having old data. now i have to make the tool take the backup for that.
and should possible to backup old data also[if any updates done on old data.]
please help to find the solution for this.
1. how can i proceed with the problem.
2. database not specified, may be MS access or Sql server 2005
3. In which i can implement this [ I am thinking of doing it in c#]
please help me to find the solution
I'm not sure why you would want to go about it this way - if you are merely trying to copy the client databases (which I interpret as being "file based") then why not simply take copies of their files as part of the wider backup strategy?
If you to write the backup stuff to place all the data in a server based RDBMS, then you are also going to have to think about how you restore that information later on - which presumably means even more coding for you.
So - I don't think this is a good idea, but if you are determined, I would start off by writing a class (which will be almost abstract) dedicated to the purpose of reading the structure of the client database (tables, fields, views etc). I'd then inherit from that to get a specific class for doing this for each individual type of client DB. Once you have that, you can use ADO.Net to read values from the tables in the Client DB, populate datatables with the information, and then write that information back out to the Server based DB.
I really can't stress enough though that I don't like this idea - it seems overly complicated, and also won't deal with functions etc.
Good luck anyway,
Martin
Advisability of doing this aside, one simple answer for a particular subset of the problem would be to create a DSN for a target SQL Server (or any server database) and in Access export table by table to the DSN. You can do this through the Access UI and it can be automated within Access with DoCmd.TransferDatabase. It can be a little fiddly figuring out the proper connect string, and you'd also need to do something about renaming the exported tables so there are no collisions between databases, but that can be handled quite easily in a bit of VBA code.
I post this only because many people overlook the Access capability to export to an ODBC DSN, which requires no writing of DDL and so forth. It may or may not make correct choices about target data types, though, so you'd have to see in any particular situation if it's good enough or not.