LS,

When writing joins where tables are involved that have the same fieldnames
dbIsam 3.3 wrote it as: custID, custID_1.
EDB however writes it as custID1. Is this standard SQL2003 or is there
another reason for changing it?

I was trying to switch from dbIsam3 to EDB queries that were source to FR
reports, and I thought that was easy because only the querysource was
different. Now it seems that the output changed too, so I have to change all
my reports that uses the 'old style' fieldnames. I have hundreds reports and
a lot of customers, so....

Is there a way of easing the pain -of which I haven't thought of, or is it
just the way it is?

Regards, Harry

Harry,

<< When writing joins where tables are involved that have the same
fieldnames dbIsam 3.3 wrote it as: custID, custID_1.  EDB however writes it
as custID1. Is this standard SQL2003 or is there another reason for changing
it? >>

I'm afraid that it was simply arbitrary, however I'm not sure if I should
change it now because it may break new EDB applications.

--
Tim Young
Elevate Software
www.elevatesoft.com

Harry, wouldn't it be easier to edit your queries to e.g.

  select a.custID as "custID", b.custID as "custID_1"

Or else, let your text editor run a search and replace on your .fr3
files (aren't they some species of XML text?)



Harry de Boer wrote:
> LS,
>
> When writing joins where tables are involved that have the same fieldnames
> dbIsam 3.3 wrote it as: custID, custID_1.
> EDB however writes it as custID1. Is this standard SQL2003 or is there
> another reason for changing it?
>
> I was trying to switch from dbIsam3 to EDB queries that were source to FR
> reports, and I thought that was easy because only the querysource was
> different. Now it seems that the output changed too, so I have to change all
> my reports that uses the 'old style' fieldnames. I have hundreds reports and
> a lot of customers, so....
>
> Is there a way of easing the pain -of which I haven't thought of, or is it
> just the way it is?

Tim,

I don't know if there are already a lot of new apps with EDB 'live'. Could
you hold a poll for this on your site or mail EDB owners if this would
affect them. I understand I'm asking a lot of you here, but as you can see,
it would be great for us to port apps with a little more ease. I don't know
how this was handled in dbIsam4, maybe more users have the same problems?

Regards, Harry

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in bericht
news:471CE658-1EDB-450E-B554-A924B74821BE@news.elevatesoft.com...
> Harry,
>
> << When writing joins where tables are involved that have the same
> fieldnames dbIsam 3.3 wrote it as: custID, custID_1.  EDB however writes
it
> as custID1. Is this standard SQL2003 or is there another reason for
changing
> it? >>
>
> I'm afraid that it was simply arbitrary, however I'm not sure if I should
> change it now because it may break new EDB applications.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Charles,

The problem is that we use a visual querybuilder which users also can build
queries and the build reports. So it's automated. Replacing is also
difficult because it's still FR2.4 -no xml- and the report is stored in a
Blob field.

Regards, Harry

"Charles Tyson" <cmtNOSPAMzeebox@sbcglobal.net> schreef in bericht
news:9A925802-1B03-4008-BC11-2C7C9E0752B0@news.elevatesoft.com...
> Harry, wouldn't it be easier to edit your queries to e.g.
>
>    select a.custID as "custID", b.custID as "custID_1"
>
> Or else, let your text editor run a search and replace on your .fr3
> files (aren't they some species of XML text?)
>
>
>
> Harry de Boer wrote:
> > LS,
> >
> > When writing joins where tables are involved that have the same
fieldnames
> > dbIsam 3.3 wrote it as: custID, custID_1.
> > EDB however writes it as custID1. Is this standard SQL2003 or is there
> > another reason for changing it?
> >
> > I was trying to switch from dbIsam3 to EDB queries that were source to
FR
> > reports, and I thought that was easy because only the querysource was
> > different. Now it seems that the output changed too, so I have to change
all
> > my reports that uses the 'old style' fieldnames. I have hundreds reports
and
> > a lot of customers, so....
> >
> > Is there a way of easing the pain -of which I haven't thought of, or is
it
> > just the way it is?

Harry,

<< I don't know if there are already a lot of new apps with EDB 'live'.
Could you hold a poll for this on your site or mail EDB owners if this would
affect them. I understand I'm asking a lot of you here, but as you can see,
it would be great for us to port apps with a little more ease. I don't know
how this was handled in dbIsam4, maybe more users have the same problems? >>

I'll have to see about doing this after 1.06 is out.  It's something that
doesn't require a lot of work, but I still have to be careful about such a
change.

--
Tim Young
Elevate Software
www.elevatesoft.com

> The problem is that we use a visual querybuilder

Which one, if I may ask?  And how do you like it?

Thanks

John,

VQB from ModeSoft, but it's just for dbIsam 3x, so we have to make another
choice when migrating to EDB. It was in our opinion the best querybuilder
there was -not well known to our suprise-, very flexible.

Regards, Harry

"John Seward" <no@spam.com> schreef in bericht
news:xn0fdhw2qc3rj3000@news.elevatesoft.com...
> > The problem is that we use a visual querybuilder
>
> Which one, if I may ask?  And how do you like it?
>
> Thanks

Harry,

> -not well known to our suprise-

Not too well known to Google either! I can't seem to find it.


> so we have to make another choice when migrating to EDB

I think there will be a number of us doing that...


Thanks again.