On Wednesday 18 Jul 2007, [EMAIL PROTECTED] wrote:
> > Or just more to a freeier database like MySQL or PostgreSQL.
>
> Of course MySQL (which I'm a huge fan of) now effectively charges for
> the Windows version (or at least they're not compiling it)
*Eh* ?
http://dev.mysql.com/downloads/mysql/5.0
On 7/18/07, Kris Jones <[EMAIL PROTECTED]> wrote:
> The data is quite volatile. The schema typically has some changes
> during each release cycle. We currently point at shared DBs, which I'm
> thinking is the direction we'll stick with. But we are talking about
> all of the suggestions mentioned he
On 7/18/07, Tom Chiverton <[EMAIL PROTECTED]> wrote:
> On Tuesday 17 Jul 2007, [EMAIL PROTECTED] wrote:
> > also pony up the $50/per head for MSSQL Developer edition
>
> Or just more to a freeier database like MySQL or PostgreSQL.
Of course MySQL (which I'm a huge fan of) now effectively charges f
The data is quite volatile. The schema typically has some changes
during each release cycle. We currently point at shared DBs, which I'm
thinking is the direction we'll stick with. But we are talking about
all of the suggestions mentioned here. I can see the benefit in having
local DB as well--in f
$50/per head is not the issue. Our application runs against MS SQL,
and given it's enterprise nature is likely to stay there. If there
were to be a move (very, very doubtful), it would be to Oracle. Not
casting stones at MySQL or PostrgreSQL--they're great. Just not
appropriate for our specific app
On Tuesday 17 Jul 2007, [EMAIL PROTECTED] wrote:
> As for running local DBs, not sure that is an option as our DB is
> large. That would mean regular downloads/restores on every dev
> station? This does beg the question of how we'll manage keeping our
> dev data in tune. It's time consuming with 1
On Tuesday 17 Jul 2007, [EMAIL PROTECTED] wrote:
> also pony up the $50/per head for MSSQL Developer edition
Or just more to a freeier database like MySQL or PostgreSQL.
--
Tom Chiverton
This email is sent for and on behalf of Halliwells LL
> -Original Message-
> From: John Paul Ashenfelter [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 18 July 2007 5:08 AM
> To: CF-Talk
> Subject: Re: SOT: managing multiple dev environments
>
>
> There's two pieces, right -- schema, and data. Developers need t
On 7/17/07, Kris Jones <[EMAIL PROTECTED]> wrote:
> Thanks so much Barney. We had written a tool to do cross-site updates
> for SQL integration, but it hasn't been proven-out yet, so it'll be
> good to see how your tool handles this issue. Will download and read
> included docs now!
>
> Tom & John,
Thanks so much Barney. We had written a tool to do cross-site updates
for SQL integration, but it hasn't been proven-out yet, so it'll be
good to see how your tool handles this issue. Will download and read
included docs now!
Tom & John, we do use virtual dirs in IIS for handling different
clients
On 7/17/07, Tom Chiverton <[EMAIL PROTECTED]> wrote:
> On Tuesday 17 Jul 2007, [EMAIL PROTECTED] wrote:
> > What are others doing to address similar problems?
>
> One named-based virtual host in the webserver for each client/option springs
> to mind.
I'd second that. The only other way is to only
If the synchronizing the databases is the big issue, check out my
schema management tool
(http://www.barneyb.com/barneyblog/2007/07/13/schema-tool-update/).
It's designed to manage that exact problem. I use it to keep my
office, laptop, and home workstation in sync, but you could use it to
keep se
On Tuesday 17 Jul 2007, [EMAIL PROTECTED] wrote:
> What are others doing to address similar problems?
One named-based virtual host in the webserver for each client/option springs
to mind.
--
Tom Chiverton
This email is sent for and on beha
13 matches
Mail list logo
