Board index » delphi » MSSQL 7.0 dbo and Indexes

MSSQL 7.0 dbo and Indexes

I am porting an App from Paradox to MS SQL 7.0 and found that when trying to
open a table in MSSQL and do a 'Findkey' on it I am getting a message
stating that the dataset is not indexed.  My code relied on the Primary key
being the default index.

SO, i wrote a little app to test things out on MSSQL and found that it does
not seem to choose an index unless I prefix the table name with 'dbo.'.  Is
there a way (setting etc) that I can get around this ?

Thanks,
-Orren

 

Re:MSSQL 7.0 dbo and Indexes


My app currently relies too heavily on the findkey at this point to remove
it....I also plan on allowing for MSSQL or Paradox to run the app.  I may go
ahead and do what your suggesting...but my first step is working with what I
got.

Thanks for the advice, I will search the groups for tips.
Any suggestions for getting around dbo/index problem though ?

Quote
cbaugh wrote in message <86i8hq$n...@bornews.borland.com>...
>Much better advise it to toss out your findkey and use a tquery with
>a where clause.  Search the groups for a lot of "tips" on what to do and
>what not to do when coming from Paradox.

>Craig Baugh

Re:MSSQL 7.0 dbo and Indexes


Much better advise it to toss out your findkey and use a tquery with
a where clause.  Search the groups for a lot of "tips" on what to do and
what not to do when coming from Paradox.

Craig Baugh

Quote
Orren <Orren.grush...@goldmanmarcus.com> wrote in message news:86i08v$ms614@bornews.borland.com...
> I am porting an App from Paradox to MS SQL 7.0 and found that when trying to
> open a table in MSSQL and do a 'Findkey' on it I am getting a message
> stating that the dataset is not indexed.  My code relied on the Primary key
> being the default index.

> SO, i wrote a little app to test things out on MSSQL and found that it does
> not seem to choose an index unless I prefix the table name with 'dbo.'.  Is
> there a way (setting etc) that I can get around this ?

> Thanks,
> -Orren

Re:MSSQL 7.0 dbo and Indexes


Well you could do something where you toggle the code that gets executed
based on which database they are running. However, I agree with the
previous poster. If you keep you TTables and try to use MSSQL (or any
SQL based RDBMS), your performance will suck and you will have a lot of
unhappy, unsatisfied customers. BTW, the DataSet.Locate will do a lot of
what I think FindKey does for you in a ttable enviroment, so switching
might not be too bad after all...
Quote
Orren wrote:

> My app currently relies too heavily on the findkey at this point to remove
> it....I also plan on allowing for MSSQL or Paradox to run the app.  I may go
> ahead and do what your suggesting...but my first step is working with what I
> got.

Re:MSSQL 7.0 dbo and Indexes


Please, please don't do it.  I can't stress it enough.  I've seen apps that ran faster
on paradox tables then on sql tables for the exact reason of what you are doing.
If your app can run on both sql server and paradox tables, well I imagine that
scalability will be close to 0%.  Think about what happens when you do a findkey
on paradox.  You have the table opened to that index, and you scan on it.  Now,
do that on sql server, get ready to bring all of the records down.  And I'm sure you are
using ttables, the number one gotcha all time of killing sql server performance.   Stop
and scan these newsgroups before you go further. You'll thank me once you stop cursing
at me:)..

Craig Baugh

Quote
Orren <Orren.grush...@goldmanmarcus.com> wrote in message news:86i90b$n425@bornews.borland.com...
> My app currently relies too heavily on the findkey at this point to remove
> it....I also plan on allowing for MSSQL or Paradox to run the app.  I may go
> ahead and do what your suggesting...but my first step is working with what I
> got.

> Thanks for the advice, I will search the groups for tips.
> Any suggestions for getting around dbo/index problem though ?

> cbaugh wrote in message <86i8hq$n...@bornews.borland.com>...
> >Much better advise it to toss out your findkey and use a tquery with
> >a where clause.  Search the groups for a lot of "tips" on what to do and
> >what not to do when coming from Paradox.

> >Craig Baugh

Re:MSSQL 7.0 dbo and Indexes


Well if you absolutely *have* to do it this way, I'd recommend creating a
TTable descendant and having it automatically fix the table name to add the
dbo. prefix if it's not already there.

Jamie

Quote
"Orren" <Orren.grush...@goldmanmarcus.com> wrote in message

news:86i90b$n425@bornews.borland.com...
Quote
> My app currently relies too heavily on the findkey at this point to remove
> it....I also plan on allowing for MSSQL or Paradox to run the app.  I may
go
> ahead and do what your suggesting...but my first step is working with what
I
> got.

> Thanks for the advice, I will search the groups for tips.
> Any suggestions for getting around dbo/index problem though ?

> cbaugh wrote in message <86i8hq$n...@bornews.borland.com>...
> >Much better advise it to toss out your findkey and use a tquery with
> >a where clause.  Search the groups for a lot of "tips" on what to do and
> >what not to do when coming from Paradox.

> >Craig Baugh

Re:MSSQL 7.0 dbo and Indexes


I scanned through many of the C/S tips, printed them, memorized them and had
them framed and yes I am scared.  The application won't be using both
Paradox and SQL at the same time (just to be clear), it will use one or the
other depending on user preferences etc.  So I am on a tricky tightrope
here...my first priority is to get it to work with minimal changes.  Do some
testing and then modify as needed.  And from what everyone is telling me is
that it will be significant changes...but first baby steps.

Thanks for all the suggestions and tips. I thought there was a setting
(grant etc) or a way to not have to state the owner in front of the
tablename.  I know there was using db2 with other development apps (I just
can't remember how we did it).  I guess I will have to modify it via
procedure or descendant.  It looks like I will have to have some sort of
"toggle" in the code at some point to handle the SQL side, as Bradford
suggested.

Thanks again.

Quote
cbaugh wrote in message <86ij0e$n...@bornews.borland.com>...
>Please, please don't do it.  I can't stress it enough.  I've seen apps that
ran faster
>on paradox tables then on sql tables for the exact reason of what you are
doing.
>If your app can run on both sql server and paradox tables, well I imagine
that
>scalability will be close to 0%.  Think about what happens when you do a
findkey
>on paradox.  You have the table opened to that index, and you scan on it.
Now,
>do that on sql server, get ready to bring all of the records down.  And I'm
sure you are
>using ttables, the number one gotcha all time of killing sql server
performance.   Stop
>and scan these newsgroups before you go further. You'll thank me once you
stop cursing
>at me:)..

>Craig Baugh

Re:MSSQL 7.0 dbo and Indexes


You only define the primarykey property into database bat not the index and
the findkey use the index define it using create index and all your problems
are finished

Orren escribi en mensaje <86i08v$ms...@bornews.borland.com>...

Quote
>I am porting an App from Paradox to MS SQL 7.0 and found that when trying
to
>open a table in MSSQL and do a 'Findkey' on it I am getting a message
>stating that the dataset is not indexed.  My code relied on the Primary key
>being the default index.

>SO, i wrote a little app to test things out on MSSQL and found that it does
>not seem to choose an index unless I prefix the table name with 'dbo.'.  Is
>there a way (setting etc) that I can get around this ?

>Thanks,
>-Orren

Re:MSSQL 7.0 dbo and Indexes


I wish you luck.  I think if you will reread the newsgroups you will find that the
idea of a toggle in your code is a rather poor idea.  I earlier posted a list of what
I have found (from experience, talking to others and these newsgroups) my top
ten list for C/S development. I believe you'll find that most of these you will be in
violation of.  And if you spend enough time to truly find a way to "flip a switch", you
will find that it would have been far easier to simply have two completely different products
up front. And again, I apologize if I'm being unfriendly, I'm really trying to point you in the
direction of understanding the differences between a paradox app and a good c/s app.

HTH,

Craig Baugh

Quote
Orren <Orren.grush...@goldmanmarcus.com> wrote in message news:86kqqd$ond15@bornews.borland.com...
> I scanned through many of the C/S tips, printed them, memorized them and had
> them framed and yes I am scared.  The application won't be using both
> Paradox and SQL at the same time (just to be clear), it will use one or the
> other depending on user preferences etc.  So I am on a tricky tightrope
> here...my first priority is to get it to work with minimal changes.  Do some
> testing and then modify as needed.  And from what everyone is telling me is
> that it will be significant changes...but first baby steps.

> Thanks for all the suggestions and tips. I thought there was a setting
> (grant etc) or a way to not have to state the owner in front of the
> tablename.  I know there was using db2 with other development apps (I just
> can't remember how we did it).  I guess I will have to modify it via
> procedure or descendant.  It looks like I will have to have some sort of
> "toggle" in the code at some point to handle the SQL side, as Bradford
> suggested.

> Thanks again.

> cbaugh wrote in message <86ij0e$n...@bornews.borland.com>...
> >Please, please don't do it.  I can't stress it enough.  I've seen apps that
> ran faster
> >on paradox tables then on sql tables for the exact reason of what you are
> doing.
> >If your app can run on both sql server and paradox tables, well I imagine
> that
> >scalability will be close to 0%.  Think about what happens when you do a
> findkey
> >on paradox.  You have the table opened to that index, and you scan on it.
> Now,
> >do that on sql server, get ready to bring all of the records down.  And I'm
> sure you are
> >using ttables, the number one gotcha all time of killing sql server
> performance.   Stop
> >and scan these newsgroups before you go further. You'll thank me once you
> stop cursing
> >at me:)..

> >Craig Baugh

Re:MSSQL 7.0 dbo and Indexes


Craig,

Sorry, do you mind to email me your top ten tips or to point out where I can
find it?

Thanks

Peter Dam

Quote
cbaugh <cba...@home.com> wrote in message

news:86mtd6$poo14@bornews.borland.com...
Quote
> I wish you luck.  I think if you will reread the newsgroups you will find
that the
> idea of a toggle in your code is a rather poor idea.  I earlier posted a
list of what
> I have found (from experience, talking to others and these newsgroups) my
top
> ten list for C/S development. I believe you'll find that most of these you
will be in
> violation of.  And if you spend enough time to truly find a way to "flip a
switch", you
> will find that it would have been far easier to simply have two completely
different products
> up front. And again, I apologize if I'm being unfriendly, I'm really

trying to point you in the
Quote
> direction of understanding the differences between a paradox app and a
good c/s app.

> HTH,

> Craig Baugh

> Orren <Orren.grush...@goldmanmarcus.com> wrote in message

news:86kqqd$ond15@bornews.borland.com...
Quote
> > I scanned through many of the C/S tips, printed them, memorized them and
had
> > them framed and yes I am scared.  The application won't be using both
> > Paradox and SQL at the same time (just to be clear), it will use one or
the
> > other depending on user preferences etc.  So I am on a tricky tightrope
> > here...my first priority is to get it to work with minimal changes.  Do
some
> > testing and then modify as needed.  And from what everyone is telling me
is
> > that it will be significant changes...but first baby steps.

> > Thanks for all the suggestions and tips. I thought there was a setting
> > (grant etc) or a way to not have to state the owner in front of the
> > tablename.  I know there was using db2 with other development apps (I
just
> > can't remember how we did it).  I guess I will have to modify it via
> > procedure or descendant.  It looks like I will have to have some sort of
> > "toggle" in the code at some point to handle the SQL side, as Bradford
> > suggested.

> > Thanks again.

> > cbaugh wrote in message <86ij0e$n...@bornews.borland.com>...
> > >Please, please don't do it.  I can't stress it enough.  I've seen apps
that
> > ran faster
> > >on paradox tables then on sql tables for the exact reason of what you
are
> > doing.
> > >If your app can run on both sql server and paradox tables, well I
imagine
> > that
> > >scalability will be close to 0%.  Think about what happens when you do
a
> > findkey
> > >on paradox.  You have the table opened to that index, and you scan on
it.
> > Now,
> > >do that on sql server, get ready to bring all of the records down.  And
I'm
> > sure you are
> > >using ttables, the number one gotcha all time of killing sql server
> > performance.   Stop
> > >and scan these newsgroups before you go further. You'll thank me once
you
> > stop cursing
> > >at me:)..

> > >Craig Baugh

Re:MSSQL 7.0 dbo and Indexes


No problem. I'll repost them since I've made a few changes. I should
add the caveat that this is based on BDE usage.  I'm working to put one
together for ADO usage.

*********
My top eigh{*word*249}  list.
- Use cached updates. (This allows use of the tupdatesql component).
- Don't cache updates. Call applyupdates after each one.
- Understand how locking works on your server.  (If you don't you will come to regret it.)
- If it can be done on the server, do it there.
- Code priority.
1. Make it a trigger.
2. Make it a stored procedure.
3. Make it a query called from the client.
4. Write it at the client but figure out why you can't do it at the server and then stick it at the
server.
- Use views where they make sense. Wonderful for date issues.
- Don't set requestlive to true. (Anywhere)
- Don't edit in grids.
- Use small datamods and create / destroy as needed.
- Make datamods that do one thing well. Ie, Locate screens, lookup lists.
- Don't use clientdatasets. You lose performance and gain nothing. (That I see)
- Never, ever, ever use ttables. (Kiss of death)
- Never, ever, ever use filters. Use where clauses.
- Don't use third party components without source code.
- Stay away from non dataware controls for displaying table data (lists). (ie, Not derived from
datasets.)
- Laugh at everyone who says you can take your "paradox/access app and make it c/s by changing the
alias"
- Don't ever write "while not eof" at the client.
- And .... Take everything you know about local tables and toss it out the window.

I'm sure many will disagree (and already have) but it's good food for thought.

Regards,

Craig Baugh

Quote
Peter Dam <p...@tesco.net> wrote in message news:86sd8c$t4r12@bornews.borland.com...
> Craig,

> Sorry, do you mind to email me your top ten tips or to point out where I can
> find it?

> Thanks

> Peter Dam

> cbaugh <cba...@home.com> wrote in message
> news:86mtd6$poo14@bornews.borland.com...
> > I wish you luck.  I think if you will reread the newsgroups you will find
> that the
> > idea of a toggle in your code is a rather poor idea.  I earlier posted a
> list of what
> > I have found (from experience, talking to others and these newsgroups) my
> top
> > ten list for C/S development. I believe you'll find that most of these you
> will be in
> > violation of.  And if you spend enough time to truly find a way to "flip a
> switch", you
> > will find that it would have been far easier to simply have two completely
> different products
> > up front. And again, I apologize if I'm being unfriendly, I'm really
> trying to point you in the
> > direction of understanding the differences between a paradox app and a
> good c/s app.

> > HTH,

> > Craig Baugh

> > Orren <Orren.grush...@goldmanmarcus.com> wrote in message
> news:86kqqd$ond15@bornews.borland.com...
> > > I scanned through many of the C/S tips, printed them, memorized them and
> had
> > > them framed and yes I am scared.  The application won't be using both
> > > Paradox and SQL at the same time (just to be clear), it will use one or
> the
> > > other depending on user preferences etc.  So I am on a tricky tightrope
> > > here...my first priority is to get it to work with minimal changes.  Do
> some
> > > testing and then modify as needed.  And from what everyone is telling me
> is
> > > that it will be significant changes...but first baby steps.

> > > Thanks for all the suggestions and tips. I thought there was a setting
> > > (grant etc) or a way to not have to state the owner in front of the
> > > tablename.  I know there was using db2 with other development apps (I
> just
> > > can't remember how we did it).  I guess I will have to modify it via
> > > procedure or descendant.  It looks like I will have to have some sort of
> > > "toggle" in the code at some point to handle the SQL side, as Bradford
> > > suggested.

> > > Thanks again.

> > > cbaugh wrote in message <86ij0e$n...@bornews.borland.com>...
> > > >Please, please don't do it.  I can't stress it enough.  I've seen apps
> that
> > > ran faster
> > > >on paradox tables then on sql tables for the exact reason of what you
> are
> > > doing.
> > > >If your app can run on both sql server and paradox tables, well I
> imagine
> > > that
> > > >scalability will be close to 0%.  Think about what happens when you do
> a
> > > findkey
> > > >on paradox.  You have the table opened to that index, and you scan on
> it.
> > > Now,
> > > >do that on sql server, get ready to bring all of the records down.  And
> I'm
> > > sure you are
> > > >using ttables, the number one gotcha all time of killing sql server
> > > performance.   Stop
> > > >and scan these newsgroups before you go further. You'll thank me once
> you
> > > stop cursing
> > > >at me:)..

> > > >Craig Baugh

Re:MSSQL 7.0 dbo and Indexes


Orren I was the same problem that yoo and application developed into paradox
using Findkey Master/Detail and IndexFieldNames; and I defined the same
structure in the server and define and SchemaCacheDir in Alias BDE
do all the test possible and run my application.

cbaugh escribi en mensaje <86sf0g$t...@bornews.borland.com>...

Quote
>No problem. I'll repost them since I've made a few changes. I should
>add the caveat that this is based on BDE usage.  I'm working to put one
>together for ADO usage.

>*********
>My top eigh{*word*249}  list.
>- Use cached updates. (This allows use of the tupdatesql component).
>- Don't cache updates. Call applyupdates after each one.
>- Understand how locking works on your server.  (If you don't you will come
to regret it.)
>- If it can be done on the server, do it there.
>- Code priority.
>1. Make it a trigger.
>2. Make it a stored procedure.
>3. Make it a query called from the client.
>4. Write it at the client but figure out why you can't do it at the server

and then stick it at the
Quote
>server.
>- Use views where they make sense. Wonderful for date issues.
>- Don't set requestlive to true. (Anywhere)
>- Don't edit in grids.
>- Use small datamods and create / destroy as needed.
>- Make datamods that do one thing well. Ie, Locate screens, lookup lists.
>- Don't use clientdatasets. You lose performance and gain nothing. (That I
see)
>- Never, ever, ever use ttables. (Kiss of death)
>- Never, ever, ever use filters. Use where clauses.
>- Don't use third party components without source code.
>- Stay away from non dataware controls for displaying table data (lists).

(ie, Not derived from
Quote
>datasets.)
>- Laugh at everyone who says you can take your "paradox/access app and make

it c/s by changing the
Quote
>alias"
>- Don't ever write "while not eof" at the client.
>- And .... Take everything you know about local tables and toss it out the
window.

>I'm sure many will disagree (and already have) but it's good food for
thought.

>Regards,

>Craig Baugh

>Peter Dam <p...@tesco.net> wrote in message

news:86sd8c$t4r12@bornews.borland.com...

- Show quoted text -

Quote
>> Craig,

>> Sorry, do you mind to email me your top ten tips or to point out where I
can
>> find it?

>> Thanks

>> Peter Dam

>> cbaugh <cba...@home.com> wrote in message
>> news:86mtd6$poo14@bornews.borland.com...
>> > I wish you luck.  I think if you will reread the newsgroups you will
find
>> that the
>> > idea of a toggle in your code is a rather poor idea.  I earlier posted
a
>> list of what
>> > I have found (from experience, talking to others and these newsgroups)
my
>> top
>> > ten list for C/S development. I believe you'll find that most of these
you
>> will be in
>> > violation of.  And if you spend enough time to truly find a way to
"flip a
>> switch", you
>> > will find that it would have been far easier to simply have two
completely
>> different products
>> > up front. And again, I apologize if I'm being unfriendly, I'm really
>> trying to point you in the
>> > direction of understanding the differences between a paradox app and a
>> good c/s app.

>> > HTH,

>> > Craig Baugh

>> > Orren <Orren.grush...@goldmanmarcus.com> wrote in message
>> news:86kqqd$ond15@bornews.borland.com...
>> > > I scanned through many of the C/S tips, printed them, memorized them
and
>> had
>> > > them framed and yes I am scared.  The application won't be using both
>> > > Paradox and SQL at the same time (just to be clear), it will use one
or
>> the
>> > > other depending on user preferences etc.  So I am on a tricky
tightrope
>> > > here...my first priority is to get it to work with minimal changes.
Do
>> some
>> > > testing and then modify as needed.  And from what everyone is telling
me
>> is
>> > > that it will be significant changes...but first baby steps.

>> > > Thanks for all the suggestions and tips. I thought there was a
setting
>> > > (grant etc) or a way to not have to state the owner in front of the
>> > > tablename.  I know there was using db2 with other development apps (I
>> just
>> > > can't remember how we did it).  I guess I will have to modify it via
>> > > procedure or descendant.  It looks like I will have to have some sort
of
>> > > "toggle" in the code at some point to handle the SQL side, as
Bradford
>> > > suggested.

>> > > Thanks again.

>> > > cbaugh wrote in message <86ij0e$n...@bornews.borland.com>...
>> > > >Please, please don't do it.  I can't stress it enough.  I've seen
apps
>> that
>> > > ran faster
>> > > >on paradox tables then on sql tables for the exact reason of what
you
>> are
>> > > doing.
>> > > >If your app can run on both sql server and paradox tables, well I
>> imagine
>> > > that
>> > > >scalability will be close to 0%.  Think about what happens when you
do
>> a
>> > > findkey
>> > > >on paradox.  You have the table opened to that index, and you scan
on
>> it.
>> > > Now,
>> > > >do that on sql server, get ready to bring all of the records down.
And
>> I'm
>> > > sure you are
>> > > >using ttables, the number one gotcha all time of killing sql server
>> > > performance.   Stop
>> > > >and scan these newsgroups before you go further. You'll thank me
once
>> you
>> > > stop cursing
>> > > >at me:)..

>> > > >Craig Baugh

Re:MSSQL 7.0 dbo and Indexes


Thanks for the top eigh{*word*249} list. I find it extremely useful for me - a new
comer to client/server programming area. Any tips for MS SQL7.0 using both
BDE and ADOExpress?

Peter

Quote
cbaugh <cba...@home.com> wrote in message

news:86sf0g$t586@bornews.borland.com...
Quote
> No problem. I'll repost them since I've made a few changes. I should
> add the caveat that this is based on BDE usage.  I'm working to put one
> together for ADO usage.

> *********
> My top eigh{*word*249}  list.
> - Use cached updates. (This allows use of the tupdatesql component).
> - Don't cache updates. Call applyupdates after each one.
> - Understand how locking works on your server.  (If you don't you will
come to regret it.)
> - If it can be done on the server, do it there.
> - Code priority.
> 1. Make it a trigger.
> 2. Make it a stored procedure.
> 3. Make it a query called from the client.
> 4. Write it at the client but figure out why you can't do it at the server

and then stick it at the
Quote
> server.
> - Use views where they make sense. Wonderful for date issues.
> - Don't set requestlive to true. (Anywhere)
> - Don't edit in grids.
> - Use small datamods and create / destroy as needed.
> - Make datamods that do one thing well. Ie, Locate screens, lookup lists.
> - Don't use clientdatasets. You lose performance and gain nothing. (That I
see)
> - Never, ever, ever use ttables. (Kiss of death)
> - Never, ever, ever use filters. Use where clauses.
> - Don't use third party components without source code.
> - Stay away from non dataware controls for displaying table data (lists).

(ie, Not derived from
Quote
> datasets.)
> - Laugh at everyone who says you can take your "paradox/access app and

make it c/s by changing the
Quote
> alias"
> - Don't ever write "while not eof" at the client.
> - And .... Take everything you know about local tables and toss it out the
window.

> I'm sure many will disagree (and already have) but it's good food for
thought.

> Regards,

> Craig Baugh

> Peter Dam <p...@tesco.net> wrote in message

news:86sd8c$t4r12@bornews.borland.com...

- Show quoted text -

Quote
> > Craig,

> > Sorry, do you mind to email me your top ten tips or to point out where I
can
> > find it?

> > Thanks

> > Peter Dam

> > cbaugh <cba...@home.com> wrote in message
> > news:86mtd6$poo14@bornews.borland.com...
> > > I wish you luck.  I think if you will reread the newsgroups you will
find
> > that the
> > > idea of a toggle in your code is a rather poor idea.  I earlier posted
a
> > list of what
> > > I have found (from experience, talking to others and these newsgroups)
my
> > top
> > > ten list for C/S development. I believe you'll find that most of these
you
> > will be in
> > > violation of.  And if you spend enough time to truly find a way to
"flip a
> > switch", you
> > > will find that it would have been far easier to simply have two
completely
> > different products
> > > up front. And again, I apologize if I'm being unfriendly, I'm really
> > trying to point you in the
> > > direction of understanding the differences between a paradox app and a
> > good c/s app.

> > > HTH,

> > > Craig Baugh

> > > Orren <Orren.grush...@goldmanmarcus.com> wrote in message
> > news:86kqqd$ond15@bornews.borland.com...
> > > > I scanned through many of the C/S tips, printed them, memorized them
and
> > had
> > > > them framed and yes I am scared.  The application won't be using
both
> > > > Paradox and SQL at the same time (just to be clear), it will use one
or
> > the
> > > > other depending on user preferences etc.  So I am on a tricky
tightrope
> > > > here...my first priority is to get it to work with minimal changes.
Do
> > some
> > > > testing and then modify as needed.  And from what everyone is
telling me
> > is
> > > > that it will be significant changes...but first baby steps.

> > > > Thanks for all the suggestions and tips. I thought there was a
setting
> > > > (grant etc) or a way to not have to state the owner in front of the
> > > > tablename.  I know there was using db2 with other development apps
(I
> > just
> > > > can't remember how we did it).  I guess I will have to modify it via
> > > > procedure or descendant.  It looks like I will have to have some
sort of
> > > > "toggle" in the code at some point to handle the SQL side, as
Bradford
> > > > suggested.

> > > > Thanks again.

> > > > cbaugh wrote in message <86ij0e$n...@bornews.borland.com>...
> > > > >Please, please don't do it.  I can't stress it enough.  I've seen
apps
> > that
> > > > ran faster
> > > > >on paradox tables then on sql tables for the exact reason of what
you
> > are
> > > > doing.
> > > > >If your app can run on both sql server and paradox tables, well I
> > imagine
> > > > that
> > > > >scalability will be close to 0%.  Think about what happens when you
do
> > a
> > > > findkey
> > > > >on paradox.  You have the table opened to that index, and you scan
on
> > it.
> > > > Now,
> > > > >do that on sql server, get ready to bring all of the records down.
And
> > I'm
> > > > sure you are
> > > > >using ttables, the number one gotcha all time of killing sql server
> > > > performance.   Stop
> > > > >and scan these newsgroups before you go further. You'll thank me
once
> > you
> > > > stop cursing
> > > > >at me:)..

> > > > >Craig Baugh

Re:MSSQL 7.0 dbo and Indexes


Thank you,  I will give it a shot!

Quote
Mauricio Castro wrote in message <86ktkt$on...@bornews.borland.com>...
>You only define the primarykey property into database bat not the index and
>the findkey use the index define it using create index and all your
problems
>are finished

Re:MSSQL 7.0 dbo and Indexes


Well I gave it a shot, it didn't seem to help.  Maybe I have the syntax
wrong.  I am creating a table as follows:

CREATE TABLE table1
(
col1 CHAR(10) NOT NULL,
col2 SMALLINT NOT NULL,
CONSTRAINT px_options PRIMARY KEY (col1)
)

Is this the way you are suggesting ?
If not, what is the syntax you used ?

Thanks.

Quote
Mauricio Castro wrote in message <86ktkt$on...@bornews.borland.com>...
>You only define the primarykey property into database bat not the index and
>the findkey use the index define it using create index and all your
problems
>are finished

Go to page: [1] [2]

Other Threads