On Tue, 24 Jul 2007 17:52:55 +0200 "Christophe de VIENNE" <[EMAIL PROTECTED]> wrote:
> > Hi > > 2007/7/24, michael <[EMAIL PROTECTED]>: > > > > On Tue, 24 Jul 2007 15:14:52 +0200 > > "Christophe de VIENNE" <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi, > > > > > > I'm in the same process, and very interested in the answer ! > > > > > > One idea I had is to define an universal dump format, (based for > > > example on pytables), which could be used to backup and restore > > > datas from/to various databases. > > > If this way is a good one and a good implementation proposed, it > > > could become an interesting addon to SA. > > > > > > Regards, > > > > > > Christophe > > > > > > 2007/7/24, Paul Johnston <[EMAIL PROTECTED]>: > > > > > > > > Hi, > > > > > > > > I am migrating an Access database to MSSQL server. I have coded > > > > up basic Access support for SQLAlchemy, which I'll be commiting > > > > to the 0.4 branch shortly. > > > > > > > > Using autocode, I now have a set of SQLAlchemy table > > > > definitions. My question is: what's a good way to move all the > > > > data across? > > > > > > > > Thanks for any help, > > > > > > > > Paul > > > > > > > > > > > > > > > > > With all due respect for the brilliance of SQLAlchemy.. it is not an > > operating system and not a database. > > > > Maybe I am missing the point here, but, in the two hours it took to > > get a reply to the OP, one could have output from one db (to csv) > > and import to the other one. Another alternative is to actually > > use the db functionality. MSAccess and MSSQL both start with > > 'MS'. If I am not mistaken, those are interoperable. One can set > > up a 'link' and transfer the data, no? It has been years, but I > > remember doing that. > > > > Moving data in/out of disparate data sources is a pretty common data > > wharehouse process. And if they are large datasets, native 'bulk' > > transfers are fastest. All of which can be automated... without > > intervention from the application layer. (was that blasphemy?) > > I see no blasphemy, but that does not exactly address my personal > issue (which is not exactly the same as Paul it seems). > I will have, in a few months, clients running my software on mysql, > other on mssql. I want to have a common backup format, so I can > restore any backup on any supported db, and all that should be doable > by a "Toto User" (toto=dummy). > Having it in the application layer allow me do to that. And since I > hate to re-do things, my approach will most probably to use SA to dump > and restore the datas, even if it's a bit slow (the databases are not > very big), and it will always be possible to optimize the process by > doing db-specific operations. > The pytables format looks attractive for this use because it's fast, > scalable, compresses the datas, and have generic viewer. > > My experience with SA is still a bit light, and I might say stupid > things without seeing it, but that's the general idea. > > My two cents :-) > > Regards, > > Christophe Hello Christophe, If I am reading you intent (and forgive me if I am wrong), you would like to have one backup/restore routine for the same schema but on a variety of databases. And, you want the user to be responsible for doing both actions. Your references to "universal dump format" and "common backup format" point sqarely at a flat file; which can sometimes be [tab|space|comma|pipe|etc] delimited. Since you said that your databases will be small, text is truly universal. It does not require python or any scripting language and can easily be viewable in any text editor. As a side note, I have found pipe delimited to be the least troublesome when moving between databases that have user-input data. The first thing that comes to mind is that there should probably already be an automated backup scheduled. Users will forget and when a restore is needed, they will want fresh data. Each database has their own export-to-text command and each has their own import-from-text command; and related syntax. This can be triggered with cron for all unixes; On Windows, MSSQL has its own scheduler. (Of course, one could also have a button do the same thing, in *addition* to routine backups.) Are you asking for features in SA to handle scheduled backups and user initiated restores? -- michael --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
