Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Downgrading 4.34 build 7 tables to 4.30
Wed, Jan 23 2013 8:59 PMPermanent Link

LachlanG

In case we can't resolve our other issue in a timely fashion, is it possible to use tables that have been created in 4.34 build 7 in version 4.30 without modification or should we first export them to SQL then recreate them in 4.30?

Lachlan Gemmell
Embarcadero MVP
Wed, Jan 23 2013 10:27 PMPermanent Link

Raul

Team Elevate Team Elevate

Lachlan,

Yes - that should be fine.

Looking at releases notes there has not been a db level breaking change
since 4.28 (BLOB handling change).

The only breaking changes have been in 4.30 build 5 (PrivateDir path is
now defaulted) and 4.34 (renamed runtime packages) but neither of those
affects db compatibility.

Raul

On 1/23/2013 8:59 PM, LachlanG wrote:
> In case we can't resolve our other issue in a timely fashion, is it possible to use tables that have been created in 4.34 build 7 in version 4.30 without modification or should we first export them to SQL then recreate them in 4.30?
>
> Lachlan Gemmell
> Embarcadero MVP
>
Wed, Jan 23 2013 11:12 PMPermanent Link

LachlanG

Will we then need to recompile our clients in 4.30 as well or can 4.34 clients communicate with a 4.30 server?

Lachlan Gemmell
Embarcadero MVP
Thu, Jan 24 2013 7:55 AMPermanent Link

Fernando Dias

Team Elevate Team Elevate

Lachlan,

As Raul already suggested you should contact Elevate support directly for this kind for issues but I'd like to add that you are in my opinion adding too many potential sources of problems at the same time making it hard to debug: you changed the DBISAM version, the compiler version and now wanting to mix different client and server versions...

About the server, the standard server is compiled with Delphi 7 - I've been compiling my own customized server with D2006 for a few years and everything has been working well, but D2006 is close enough to D7 as it's still full ANSI. In your place, if D7 is out of question for some reason, then I'd use D2006 or D2007 to compile the server but not one of the unicode versions.

--
Fernando Dias
[Team Elevate]
Thu, Jan 24 2013 3:19 PMPermanent Link

LachlanG

Fernando Dias wrote:

<<you changed the DBISAM version, the compiler version and now wanting to mix different client and server versions...>>

Well I don't really "want" to mix client and server versions, it would just be a test for debugging purposes, one that would be much easier to perform than replacing all the clients. I'm hoping that the advice I've received in the other thread will resolve our main issue so now I'm interested in this question primarily for educational reasons as I can't find a clear statement on this in the documentation or release notes.

Is it possible/advisable for later client versions to communicate with an earlier server version?

I would imagine that within different builds of the same point release there's probably not much of an issue but what about changes in point release such as 4.34 clients to a 4.30 server?

Lachlan Gemmell
Embarcadero MVP
Thu, Jan 24 2013 4:06 PMPermanent Link

Raul

Team Elevate Team Elevate

On 1/24/2013 3:19 PM, LachlanG wrote:
<< > Is it possible/advisable for later client versions to communicate
with an earlier server version?>>

This is not official answer but my understanding. In general it should
be OK for testing but recommendation is to always use matching versions.
I've never run into problems though mixing but only done it in dev and test.

You can mix and match 32/64 bit servers and clients so the communication
AFAIK is somewhat higher level than binary dbisam objects.

Since the dbsrvr is the only one talkign to data files so you're ok
there so the remaining issue is whteher there have been any significant
changes in client/server com or session management and such and i don't
see anything obvious being mentioned in release notes or incident reports.

Raul

Thu, Jan 24 2013 5:39 PMPermanent Link

Fernando Dias

Team Elevate Team Elevate

Raul,

<< Since the dbsrvr is the only one talkign to data files so you're ok there so the remaining issue is whteher there have been any significant changes in client/server com or session management and such and i don't see anything obvious being mentioned in release notes or incident reports.>>

Exactly. And as you, I never use different versions except in a testing environment, and as a general rule I'd say the answer is no - some versions might be compatible, and I'd say most of the times they are, but not always.

The only thing I found in the release notes that caught my attention was in the 4.33 version, where it's said that there were significant changes in both the engine and server code and as I don't know exactly what changes, the only person who can answer that for sure is Tim.

--
Fernando Dias
[Team Elevate]
Fri, Jan 25 2013 10:51 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Lachlan,

<< Well I don't really "want" to mix client and server versions, it would
just be a test for debugging purposes, one that would be much easier to
perform than replacing all the clients. I'm hoping that the advice I've
received in the other thread will resolve our main issue so now I'm
interested in this question primarily for educational reasons as I can't
find a clear statement on this in the documentation or release notes.

Is it possible/advisable for later client versions to communicate with an
earlier server version? >.

The simple answer is "yes".  The more complex answer is that sometimes there
are bugs that will cause certain client versions to not work correctly with
certain server versions, or vice-versa.  However, these are very, very rare,
and are always documented in the release notes/incident reports.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com


Image