WiX book
This may be of interest to some - it is from the wix-users email list, today: Several people from the WiX community lent a hand getting the update to the WiX book into shape. The end result covers more ground than the last version, including, of course, Burn. All in all, I'm very pleased with the end result! It's available for the Kindle on Amazon's site at: http://www.amazon.com/WiX-3-6-Developers-Installer-ebook/dp/B009YW82A0/ref=s r_1_10?ie=UTF8 http://www.amazon.com/WiX-3-6-Developers-Installer-ebook/dp/B009YW82A0/ref= sr_1_10?ie=UTF8qid=1355752765sr=8-10keywords=wix qid=1355752765sr=8-10keywords=wix And the print version should be out soon through Packt Publishers: http://www.packtpub.com/windows-installer-xml-3-6-developers-guide/book _ Ian Thomas Victoria Park, Western Australia
RE: WiX book
What about a PDF or Daisy version? From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ian Thomas Sent: Monday, December 17, 2012 9:38 AM To: ozdotnet@ozdotnet.com Subject: WiX book This may be of interest to some - it is from the wix-users email list, today: Several people from the WiX community lent a hand getting the update to the WiX book into shape. The end result covers more ground than the last version, including, of course, Burn. All in all, I'm very pleased with the end result! It's available for the Kindle on Amazon's site at: http://www.amazon.com/WiX-3-6-Developers-Installer-ebook/dp/B009YW82A0/ref=sr_1_10?ie=UTF8qid=1355752765sr=8-10keywords=wix And the print version should be out soon through Packt Publishers: http://www.packtpub.com/windows-installer-xml-3-6-developers-guide/book Ian Thomas Victoria Park, Western Australia
Managing databases
I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686. Office: 03 9589 6502 SK Pro-Active! Pty Ltd acn. 81 072 778 262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. -
Re: Managing databases
We are using a system system and we use DBUP on top of it to help us deploy to production environments. On Tue, Dec 18, 2012 at 10:36 AM, Stuart Kinnear stu...@skproactive.comwrote: Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful?
Re: Managing databases
I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear stu...@skproactive.comwrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686. Office: 03 9589 6502 SK Pro-Active! Pty Ltd acn. 81 072 778 262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. -
RE: Managing databases
Is that written in IronRuby, by any chance? From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ben Scott Sent: Monday, December 17, 2012 8:29 PM To: ozDotNet Subject: Re: Managing data I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear stu...@skproactive.commailto:stu...@skproactive.com wrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686. Office: 03 9589 6502 SK Pro-Active! Pty Ltd acn. 81 072 778 262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. -
Re: Managing databases
Just plain Ruby. I think I used RubyInstaller for Windows - http://rubyinstaller.org/ On Tue, Dec 18, 2012 at 11:33 AM, Katherine Moss katherine.m...@gordon.eduwrote: Is that written in IronRuby, by any chance? ** ** *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Ben Scott *Sent:* Monday, December 17, 2012 8:29 PM *To:* ozDotNet *Subject:* Re: Managing data ** ** I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear stu...@skproactive.com wrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. ** ** Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. ** ** Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? ** ** ** ** -- - Stuart Kinnear Mobile: 040 704 5686. Office: 03 9589 6502 SK Pro-Active! Pty Ltd acn. 81 072 778 262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. - ** **
RE: Managing databases
Interesting. I think I guessed IronRuby since that plugs right into .NET, you know? By the way, is that even still being developed? It doesn't seem that IronPython is; the last update for it is version 2.73, though C Python is all the way at 3.0. What's with that, I wonder? Maybe all of the members of those projects left or something? From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ben Scott Sent: Monday, December 17, 2012 8:38 PM To: ozDotNet Subject: Re: Managing databases Just plain Ruby. I think I used RubyInstaller for Windows - http://rubyinstaller.org/ On Tue, Dec 18, 2012 at 11:33 AM, Katherine Moss katherine.m...@gordon.edumailto:katherine.m...@gordon.edu wrote: Is that written in IronRuby, by any chance? From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ben Scott Sent: Monday, December 17, 2012 8:29 PM To: ozDotNet Subject: Re: Managing data I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear stu...@skproactive.commailto:stu...@skproactive.com wrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686. Office: 03 9589 6502 SK Pro-Active! Pty Ltd acn. 81 072 778 262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. -
Re: Managing databases
Hi Katherine, IronPython is still being actively developed and a new release is coming early 2013 (at least that's the current plan). Version 3.0 compatibility is nearly complete in the 2.7x versions of IronPython, but from memory Jeff has full completion slated sometime next year. Regards, Brenden On 18 December 2012 11:40, Katherine Moss katherine.m...@gordon.edu wrote: Interesting. I think I guessed IronRuby since that plugs right into .NET, you know? By the way, is that even still being developed? It doesn’t seem that IronPython is; the last update for it is version 2.73, though C Python is all the way at 3.0. What’s with that, I wonder? Maybe all of the members of those projects left or something? ** ** *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Ben Scott *Sent:* Monday, December 17, 2012 8:38 PM *To:* ozDotNet *Subject:* Re: Managing databases ** ** Just plain Ruby. I think I used RubyInstaller for Windows - http://rubyinstaller.org/ On Tue, Dec 18, 2012 at 11:33 AM, Katherine Moss katherine.m...@gordon.edu wrote: Is that written in IronRuby, by any chance? *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Ben Scott *Sent:* Monday, December 17, 2012 8:29 PM *To:* ozDotNet *Subject:* Re: Managing data I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear stu...@skproactive.com wrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686. Office: 03 9589 6502 SK Pro-Active! Pty Ltd acn. 81 072 778 262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. - ** **
RE: Managing databases
That's so cool. I plan to learn Python in the future. C# and PowerShell in Tandem, then Python, then EAGLE (or TCL via the .NET Framework). What else is still up in the air depending on what the heck I need to be learning for whatever I'm working on. Dang, you're on the project? That's like, awesome! It's a small world in the tech sphere, isn't it? I go by the handle chromebuster on CodePlex, if you're ever looking for me on there. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of BC Sent: Monday, December 17, 2012 8:45 PM To: ozDotNet Subject: Re: Managing databases Hi Katherine, IronPython is still being actively developed and a new release is coming early 2013 (at least that's the current plan). Version 3.0 compatibility is nearly complete in the 2.7x versions of IronPython, but from memory Jeff has full completion slated sometime next year. Regards, Brenden On 18 December 2012 11:40, Katherine Moss katherine.m...@gordon.edumailto:katherine.m...@gordon.edu wrote: Interesting. I think I guessed IronRuby since that plugs right into .NET, you know? By the way, is that even still being developed? It doesn't seem that IronPython is; the last update for it is version 2.73, though C Python is all the way at 3.0. What's with that, I wonder? Maybe all of the members of those projects left or something? From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ben Scott Sent: Monday, December 17, 2012 8:38 PM To: ozDotNet Subject: Re: Managing databases Just plain Ruby. I think I used RubyInstaller for Windows - http://rubyinstaller.org/ On Tue, Dec 18, 2012 at 11:33 AM, Katherine Moss katherine.m...@gordon.edumailto:katherine.m...@gordon.edu wrote: Is that written in IronRuby, by any chance? From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ben Scott Sent: Monday, December 17, 2012 8:29 PM To: ozDotNet Subject: Re: Managing data I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear stu...@skproactive.commailto:stu...@skproactive.com wrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686tel:040%20704%205686. Office: 03 9589 6502tel:03%209589%206502 SK Pro-Active! Pty Ltd acn. 81 072 778 262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. -
Re: Managing databases
Thanks Brendan. I used to use IronPython big time as a customisation hook. The ability to load some code from the DB as an upgrade channel was great. I really hope that it's Visual Studio experience is a lot better. In my currently role do less straight code and more functional declarative code and Iron Python would really help connect the dots. On 18 December 2012 14:52, Katherine Moss katherine.m...@gordon.edu wrote: That’s so cool. I plan to learn Python in the future. C# and PowerShell in Tandem, then Python, then EAGLE (or TCL via the .NET Framework). What else is still up in the air depending on what the heck I need to be learning for whatever I’m working on. Dang, you’re on the project? That’s like, awesome! It’s a small world in the tech sphere, isn’t it? I go by the handle chromebuster on CodePlex, if you’re ever looking for me on there. ** ** ** ** *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *BC *Sent:* Monday, December 17, 2012 8:45 PM *To:* ozDotNet *Subject:* Re: Managing databases Hi Katherine, ** ** IronPython is still being actively developed and a new release is coming early 2013 (at least that's the current plan). Version 3.0 compatibility is nearly complete in the 2.7x versions of IronPython, but from memory Jeff has full completion slated sometime next year. ** ** Regards, Brenden ** ** On 18 December 2012 11:40, Katherine Moss katherine.m...@gordon.edu wrote: Interesting. I think I guessed IronRuby since that plugs right into .NET, you know? By the way, is that even still being developed? It doesn’t seem that IronPython is; the last update for it is version 2.73, though C Python is all the way at 3.0. What’s with that, I wonder? Maybe all of the members of those projects left or something? *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Ben Scott *Sent:* Monday, December 17, 2012 8:38 PM *To:* ozDotNet *Subject:* Re: Managing databases Just plain Ruby. I think I used RubyInstaller for Windows - http://rubyinstaller.org/ On Tue, Dec 18, 2012 at 11:33 AM, Katherine Moss katherine.m...@gordon.edu wrote: Is that written in IronRuby, by any chance? *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Ben Scott *Sent:* Monday, December 17, 2012 8:29 PM *To:* ozDotNet *Subject:* Re: Managing data I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear stu...@skproactive.com wrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686. Office: 03 9589 6502 SK Pro-Active! Pty Ltd acn. 81 072 778 262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. - ** ** -- regards, Preet, Overlooking the Ocean, Auckland
RE: Managing databases
Isn't there a plugin for that? I thought that there was. Python Tools for Visual Studio, isn't it? Works for both Iron and C python, I think. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Preet Sangha Sent: Monday, December 17, 2012 9:22 PM To: ozDotNet Subject: Re: Managing databases Thanks Brendan. I used to use IronPython big time as a customisation hook. The ability to load some code from the DB as an upgrade channel was great. I really hope that it's Visual Studio experience is a lot better. In my currently role do less straight code and more functional declarative code and Iron Python would really help connect the dots. On 18 December 2012 14:52, Katherine Moss katherine.m...@gordon.edumailto:katherine.m...@gordon.edu wrote: That's so cool. I plan to learn Python in the future. C# and PowerShell in Tandem, then Python, then EAGLE (or TCL via the .NET Framework). What else is still up in the air depending on what the heck I need to be learning for whatever I'm working on. Dang, you're on the project? That's like, awesome! It's a small world in the tech sphere, isn't it? I go by the handle chromebuster on CodePlex, if you're ever looking for me on there. From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of BC Sent: Monday, December 17, 2012 8:45 PM To: ozDotNet Subject: Re: Managing databases Hi Katherine, IronPython is still being actively developed and a new release is coming early 2013 (at least that's the current plan). Version 3.0 compatibility is nearly complete in the 2.7x versions of IronPython, but from memory Jeff has full completion slated sometime next year. Regards, Brenden On 18 December 2012 11:40, Katherine Moss katherine.m...@gordon.edumailto:katherine.m...@gordon.edu wrote: Interesting. I think I guessed IronRuby since that plugs right into .NET, you know? By the way, is that even still being developed? It doesn't seem that IronPython is; the last update for it is version 2.73, though C Python is all the way at 3.0. What's with that, I wonder? Maybe all of the members of those projects left or something? From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ben Scott Sent: Monday, December 17, 2012 8:38 PM To: ozDotNet Subject: Re: Managing databases Just plain Ruby. I think I used RubyInstaller for Windows - http://rubyinstaller.org/ On Tue, Dec 18, 2012 at 11:33 AM, Katherine Moss katherine.m...@gordon.edumailto:katherine.m...@gordon.edu wrote: Is that written in IronRuby, by any chance? From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ben Scott Sent: Monday, December 17, 2012 8:29 PM To: ozDotNet Subject: Re: Managing data I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear stu...@skproactive.commailto:stu...@skproactive.com wrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686tel:040%20704%205686. Office: 03 9589 6502tel:03%209589%206502 SK Pro-Active! Pty Ltd acn. 81 072 778 262tel:072%20778%20262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. - -- regards, Preet, Overlooking the Ocean, Auckland
Re: Managing databases
Hi Preet, The latest version of the tools is excellent and updated in October for VS 2012. Dino really does an outstanding job looking after this toolset. Details are here: http://pytools.codeplex.com/releases/view/82132 Regards, Brenden On 18 December 2012 12:21, Preet Sangha preetsan...@gmail.com wrote: Thanks Brendan. I used to use IronPython big time as a customisation hook. The ability to load some code from the DB as an upgrade channel was great. I really hope that it's Visual Studio experience is a lot better. In my currently role do less straight code and more functional declarative code and Iron Python would really help connect the dots. On 18 December 2012 14:52, Katherine Moss katherine.m...@gordon.eduwrote: That’s so cool. I plan to learn Python in the future. C# and PowerShell in Tandem, then Python, then EAGLE (or TCL via the .NET Framework). What else is still up in the air depending on what the heck I need to be learning for whatever I’m working on. Dang, you’re on the project? That’s like, awesome! It’s a small world in the tech sphere, isn’t it? I go by the handle chromebuster on CodePlex, if you’re ever looking for me on there. ** ** ** ** *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *BC *Sent:* Monday, December 17, 2012 8:45 PM *To:* ozDotNet *Subject:* Re: Managing databases Hi Katherine, ** ** IronPython is still being actively developed and a new release is coming early 2013 (at least that's the current plan). Version 3.0 compatibility is nearly complete in the 2.7x versions of IronPython, but from memory Jeff has full completion slated sometime next year. ** ** Regards, Brenden ** ** On 18 December 2012 11:40, Katherine Moss katherine.m...@gordon.edu wrote: Interesting. I think I guessed IronRuby since that plugs right into .NET, you know? By the way, is that even still being developed? It doesn’t seem that IronPython is; the last update for it is version 2.73, though C Python is all the way at 3.0. What’s with that, I wonder? Maybe all of the members of those projects left or something? *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Ben Scott *Sent:* Monday, December 17, 2012 8:38 PM *To:* ozDotNet *Subject:* Re: Managing databases Just plain Ruby. I think I used RubyInstaller for Windows - http://rubyinstaller.org/ On Tue, Dec 18, 2012 at 11:33 AM, Katherine Moss katherine.m...@gordon.edu wrote: Is that written in IronRuby, by any chance? *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Ben Scott *Sent:* Monday, December 17, 2012 8:29 PM *To:* ozDotNet *Subject:* Re: Managing data I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear stu...@skproactive.com wrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686. Office: 03 9589 6502 SK Pro-Active! Pty Ltd acn. 81 072 778 262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. - ** ** -- regards, Preet, Overlooking the Ocean, Auckland
Re: Managing databases
Greetings Stuart, We use Visual Studio database projects and generate change scripts from database compare. Please take the time to look at the SSDT package available for VS 2010 (Default for VS 2012). As for managing compatibility, with application versions, we've yet to find an ideal solution... but we're still looking :-) -- Regards, noonie On 18 December 2012 10:36, Stuart Kinnear stu...@skproactive.com wrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686. Office: 03 9589 6502 SK Pro-Active! Pty Ltd acn. 81 072 778 262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. -
Re: Managing databases
Hi Katherine, More of an avid supporter / user than on the project per se :) Planning to contribute sadly hasn't actually manifested in contributing (but part of the 2013 resolutions!). Regards, Brenden On 18 December 2012 11:52, Katherine Moss katherine.m...@gordon.edu wrote: That’s so cool. I plan to learn Python in the future. C# and PowerShell in Tandem, then Python, then EAGLE (or TCL via the .NET Framework). What else is still up in the air depending on what the heck I need to be learning for whatever I’m working on. Dang, you’re on the project? That’s like, awesome! It’s a small world in the tech sphere, isn’t it? I go by the handle chromebuster on CodePlex, if you’re ever looking for me on there. ** ** ** ** *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *BC *Sent:* Monday, December 17, 2012 8:45 PM *To:* ozDotNet *Subject:* Re: Managing databases Hi Katherine, ** ** IronPython is still being actively developed and a new release is coming early 2013 (at least that's the current plan). Version 3.0 compatibility is nearly complete in the 2.7x versions of IronPython, but from memory Jeff has full completion slated sometime next year. ** ** Regards, Brenden ** ** On 18 December 2012 11:40, Katherine Moss katherine.m...@gordon.edu wrote: Interesting. I think I guessed IronRuby since that plugs right into .NET, you know? By the way, is that even still being developed? It doesn’t seem that IronPython is; the last update for it is version 2.73, though C Python is all the way at 3.0. What’s with that, I wonder? Maybe all of the members of those projects left or something? *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Ben Scott *Sent:* Monday, December 17, 2012 8:38 PM *To:* ozDotNet *Subject:* Re: Managing databases Just plain Ruby. I think I used RubyInstaller for Windows - http://rubyinstaller.org/ On Tue, Dec 18, 2012 at 11:33 AM, Katherine Moss katherine.m...@gordon.edu wrote: Is that written in IronRuby, by any chance? *From:* ozdotnet-boun...@ozdotnet.com [mailto: ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Ben Scott *Sent:* Monday, December 17, 2012 8:29 PM *To:* ozDotNet *Subject:* Re: Managing data I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear stu...@skproactive.com wrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686. Office: 03 9589 6502 SK Pro-Active! Pty Ltd acn. 81 072 778 262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office. - ** **
RE: Managing databases
Nice. I'm grabbing that when I get a chance. From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of BC Sent: Monday, December 17, 2012 9:25 PM To: ozDotNet Subject: Re: Managing databases Hi Preet, The latest version of the tools is excellent and updated in October for VS 2012. Dino really does an outstanding job looking after this toolset. Details are here: http://pytools.codeplex.com/releases/view/82132 Regards, Brenden On 18 December 2012 12:21, Preet Sangha preetsan...@gmail.commailto:preetsan...@gmail.com wrote: Thanks Brendan. I used to use IronPython big time as a customisation hook. The ability to load some code from the DB as an upgrade channel was great. I really hope that it's Visual Studio experience is a lot better. In my currently role do less straight code and more functional declarative code and Iron Python would really help connect the dots. On 18 December 2012 14:52, Katherine Moss katherine.m...@gordon.edumailto:katherine.m...@gordon.edu wrote: That's so cool. I plan to learn Python in the future. C# and PowerShell in Tandem, then Python, then EAGLE (or TCL via the .NET Framework). What else is still up in the air depending on what the heck I need to be learning for whatever I'm working on. Dang, you're on the project? That's like, awesome! It's a small world in the tech sphere, isn't it? I go by the handle chromebuster on CodePlex, if you're ever looking for me on there. From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of BC Sent: Monday, December 17, 2012 8:45 PM To: ozDotNet Subject: Re: Managing databases Hi Katherine, IronPython is still being actively developed and a new release is coming early 2013 (at least that's the current plan). Version 3.0 compatibility is nearly complete in the 2.7x versions of IronPython, but from memory Jeff has full completion slated sometime next year. Regards, Brenden On 18 December 2012 11:40, Katherine Moss katherine.m...@gordon.edumailto:katherine.m...@gordon.edu wrote: Interesting. I think I guessed IronRuby since that plugs right into .NET, you know? By the way, is that even still being developed? It doesn't seem that IronPython is; the last update for it is version 2.73, though C Python is all the way at 3.0. What's with that, I wonder? Maybe all of the members of those projects left or something? From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ben Scott Sent: Monday, December 17, 2012 8:38 PM To: ozDotNet Subject: Re: Managing databases Just plain Ruby. I think I used RubyInstaller for Windows - http://rubyinstaller.org/ On Tue, Dec 18, 2012 at 11:33 AM, Katherine Moss katherine.m...@gordon.edumailto:katherine.m...@gordon.edu wrote: Is that written in IronRuby, by any chance? From: ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.commailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ben Scott Sent: Monday, December 17, 2012 8:29 PM To: ozDotNet Subject: Re: Managing data I have a similar system but I have a simple ruby script that applies migration scripts. I can run it against development databases and when I'm deploying a new version of the system I just run it against the production database. It includes a bootstrap migration to create the schema version table, and if the first migration is a dump of the existing schema and you insert the migration record on production you can create development databases totally in script. I've open sourced the script at https://github.com/swxben/Shu-Er/tree/master/ruby/database_migrations On Tue, Dec 18, 2012 at 9:36 AM, Stuart Kinnear stu...@skproactive.commailto:stu...@skproactive.com wrote: I guess this is an age old problem, managing database changes such that they respect applications dependent on them. We are bolting more applications to a couple of sql databases so the management exercise is becoming more complex, risky and expensive to maintain. Currently we have a database version number, use schema naming for application specific views and procedures and have a folder of each change in sequential order that has to be applied to production. Over the holiday break I thought I might research how we can improve our approach. What systems have you or your organisations adopted to keep it all under control , and are they successful? -- - Stuart Kinnear Mobile: 040 704 5686tel:040%20704%205686. Office: 03 9589 6502tel:03%209589%206502 SK Pro-Active! Pty Ltd acn. 81 072 778 262tel:072%20778%20262 PO Box 6117 Cromer, Vic 3193. Australia Business software developers. SQL Server, Visual Basic, C# , Asp.Net, Microsoft Office.
