parameter passing problem

why this wont work?

error:
Exception Details: System.Data.SqlClient.SqlException: Procedure or Function 'test1' expects parameter '@.cid', which was not supplied.

.............................................................
ASPX CODE:
string cid12;
cid12 = "user5";
// Connection
ConnectionStringSettings mysettings;
mysettings = System.Configuration.ConfigurationManager.ConnectionStrings["dbase1_connection"];
string myConnectionString = mysettings.ConnectionString;
SqlConnection conn1 = new SqlConnection(myConnectionString);

SqlCommand cmd = new SqlCommand();
cmd.Connection = conn1;
cmd.CommandText = "test1";
cmd.CommandType = CommandType.StoredProcedure;

SqlParameter param = cmd.Parameters.Add("@.cid", SqlDbType.NChar, 20);
param.Direction = ParameterDirection.Input;
param.Value = cid12;

conn1.Open();
cmd.ExecuteNonQuery();
conn1.Close();
.............................................................

STORED PROCEDURE:
ALTER PROCEDURE dbo.test1
(
@.cid nvarchar(20)
)
AS
/* SET NOCOUNT ON */
select tech_id, customer_id, issue_main from [case] where customer_id = @.cid
--GO
RETURN

.............................................................

im using asp.net, C#, and sql express
forgive me. im new to this .net
PLS HELP

pls ignore the post above. i found out that nothing is wrong with that code. i discovered that one on my grid view tables is causing the issue and it is indeed not passing a parameter and thats the reason why i have wasted 12hrs looking at my monitor. hehehe.

my fault. im just human. forgive me.

thanks to you all.

parameter passing problem

why this wont work?
error:
Exception Details: System.Data.SqlClient.SqlException: Procedure or Function 'test1' expects parameter '@.cid', which was not supplied.
.................................................................................
ASPX CODE:
string cid12;
cid12 = "user5";
// Connection
ConnectionStringSettings mysettings;
mysettings = System.Configuration.ConfigurationManager.ConnectionStrings["dbase1_connection"];
string myConnectionString = mysettings.ConnectionString;
SqlConnection conn1 = new SqlConnection(myConnectionString);
SqlCommand cmd = new SqlCommand();
cmd.Connection = conn1;
cmd.CommandText = "test1";
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter param = cmd.Parameters.Add("@.cid", SqlDbType.NChar, 20);
param.Direction = ParameterDirection.Input;
param.Value = cid12;

conn1.Open();
cmd.ExecuteNonQuery();
conn1.Close();
.................................................................................
STORED PROCEDURE:
ALTER PROCEDURE dbo.test1
(
@.cid nvarchar(20)
)
AS
/* SET NOCOUNT ON */
select tech_id, customer_id, issue_main from [case] where customer_id = @.cid
--GO
RETURN
.................................................................................
im using asp.net, C#, and sql express
forgive me. im new to this .net
PLS HELP

forgive me. i found out that the codes above are just ok. i found out that one of my grid table is the one causing the problem - it is not passing a parameter. hehehe. my fault. im just human.

thanks to you all.

parameter cannot set the command text for dataset

Hello

I get the following error in a very quick test system i created:

An error occurred during local report processing.

An error has occurred during report processing.

Cannot set the command text for data set 'test'.

Error during processing of the CommandText expression of dataset 'test'.

My sql is:

= "select T.testid, T.test from test T " & Iif(Parameters!test1.Value = 1, "", "Where T.testid = " & Parameters!test1.Value)

There is nothing obviously wrong in the code as far as i can see

The parameter 'test1' is of type 'string'

The database 'test' has 2 columns of type 'smallint' and 'Name:nvarchar(50)'

I am at a loss, as this query is really simple, and is similar to the example query set up my microsoft which works fine

Thanks

t.test from test?

You tried running this in sql?

|||

Yes, it works fine in sql if you strip out the bits that obviously wont work in query analyser

this works:

= "select T.testid, T.test from test T " & Iif(1 = 1, "", "Where T.testid = 1" )

this does not:

= "select T.testid, T.test from test T " & Iif(1 = 1, "", "Where T.testid = " & Parameters!test1.Value)

why?

there is a parameter called test1

|||

Found the answer!

You have to have another table with a different name into which the parameter links (in the section 'available values' / 'from query')

I created another table called test2, et voila! it works

Parallel vs. serial plan

Hi,
What would be the advantages of lengthy report parallel vs.
serial execution, say on a 4-way SMP system, if the query
in itself is not able to produce sustained load of more
than 4 seconds on a single CPU of the system. I'm using MS
SQL Server 2000 on MS Windows 2000 with the lastest service
packs.
Many thanks,
OskOsk wrote:
> Hi,
> What would be the advantages of lengthy report parallel vs.
> serial execution, say on a 4-way SMP system, if the query
> in itself is not able to produce sustained load of more
> than 4 seconds on a single CPU of the system. I'm using MS
> SQL Server 2000 on MS Windows 2000 with the lastest service
> packs.
I would say that 4 seconds is a long time in the CPU world. It may not
be an issue if this is run off-hours, but during production hours, if
run many times, it could be more of an issue. Parallel executions
generally consume more CPU than their single-CPU brothers. It's just
more costly to manage parallel executions. So in your case, you are
potentially tying up one CPU out of four for four seconds, leaving the
other three to perform other tasks. With a parallel plan, depending on
how many CPUs SQL Server chooses to use, you'd end up tying up more CPU
for more than four CPU seconds, but the query could finish in 2.5
seconds.
Are you saying you have disabled parallel plans for this query using a
MAXDOP hint or have changed the corresponding server setting to prevent
parallel executions?
David Gugick
Imceda Software
www.imceda.com|||SQL-Server does not know how important a particular query is for you. It
doesn't discriminate queries that way. It just estimates (for each
query) whether executing the parallel plan is likely to be faster than
the serial plan. If it is, and the server is not too stressed, then it
will execute the parallel plan. Otherwise, it will execute the serial
plan.
However, there is a threshold below which a parallel plan will not be
considered. By default, this "cost threshold for parallelism" is set to
5. With this setting, SQL-Server will not consider a parallel plan if
the estimated execution time of the serial plan is less than 5 seconds.
Hope this helps,
Gert-Jan
Osk wrote:
> Hi,
> What would be the advantages of lengthy report parallel vs.
> serial execution, say on a 4-way SMP system, if the query
> in itself is not able to produce sustained load of more
> than 4 seconds on a single CPU of the system. I'm using MS
> SQL Server 2000 on MS Windows 2000 with the lastest service
> packs.
> --
> Many thanks,
> Osk|||Yes, I have changed the 'max degree of parallelism' server
setting to 1. So as I understand it now, when the optimizer
thinks the query can benefit from executing in parllel at
the same time when the rest of CPUs are more or less idle
then, despite the parallel plan being more costly in terms
of CPU time, the query will return results faster. So I
need look at what kind of load is placed on the rest of
CPUs during the time the query runs to determine whether
there will be any benefit or parallelism.

>--Original Message--
>Osk wrote:
>I would say that 4 seconds is a long time in the CPU
world. It may not
>be an issue if this is run off-hours, but during
production hours, if
>run many times, it could be more of an issue. Parallel
executions
>generally consume more CPU than their single-CPU brothers.
It's just
>more costly to manage parallel executions. So in your
case, you are
>potentially tying up one CPU out of four for four seconds,
leaving the
>other three to perform other tasks. With a parallel plan,
depending on
>how many CPUs SQL Server chooses to use, you'd end up
tying up more CPU
>for more than four CPU seconds, but the query could finish
in 2.5
>seconds.
>Are you saying you have disabled parallel plans for this
query using a
>MAXDOP hint or have changed the corresponding server
setting to prevent
>parallel executions?
>--
>David Gugick
>Imceda Software
>www.imceda.com
>.
>|||anonymous@.discussions.microsoft.com wrote:
> Yes, I have changed the 'max degree of parallelism' server
> setting to 1. So as I understand it now, when the optimizer
> thinks the query can benefit from executing in parllel at
> the same time when the rest of CPUs are more or less idle
> then, despite the parallel plan being more costly in terms
> of CPU time, the query will return results faster. So I
> need look at what kind of load is placed on the rest of
> CPUs during the time the query runs to determine whether
> there will be any benefit or parallelism.
>
I thik you might be overthinking this a bit. Why have you decided to
change the MAX degree OF PARALLELISM on the server and not let SQL
Server manage parallel queries on its own? Occasionally, someone reports
an issue with a parallel plan which can be easily fixed with a MAXDOP
(1) in the query.
David Gugick
Imceda Software
www.imceda.com|||Well, that's how I understood it. If I'm wrong please
correct me.
I've set the server-wide MAXDOP to 1 because of two reasons:
1) to see whether placing the load of reports on a single
CPU will allow smaller queries have fulfilled their CPU
needs quicker than when they would have to wait for a
report to execute in parallel on all CPUs (although this
seems to work only in cases when the report doesn't hold
locks incompatible with other query's locks)
2) I can't provide hints at the T-SQL level yet
Thanks,
Osk

>--Original Message--
>anonymous@.discussions.microsoft.com wrote:
>I thik you might be overthinking this a bit. Why have you
decided to
>change the MAX degree OF PARALLELISM on the server and not
let SQL
>Server manage parallel queries on its own? Occasionally,
someone reports
>an issue with a parallel plan which can be easily fixed
with a MAXDOP
>(1) in the query.
>--
>David Gugick
>Imceda Software
>www.imceda.com
>.
>|||Osk wrote:
> Well, that's how I understood it. If I'm wrong please
> correct me.
> I've set the server-wide MAXDOP to 1 because of two reasons:
> 1) to see whether placing the load of reports on a single
> CPU will allow smaller queries have fulfilled their CPU
> needs quicker than when they would have to wait for a
> report to execute in parallel on all CPUs (although this
> seems to work only in cases when the report doesn't hold
> locks incompatible with other query's locks)
> 2) I can't provide hints at the T-SQL level yet
>
MAXDOP at the server level does not mean that reports are only going to
run on a single CPU. Unless what you're saying is that only one report
can run at a time and because of that it will only run on a single CPU.
MAXDOP 1 just means SQL Server will only use a single CPU for a query,
but the CPU used could be any available (maybe you already understood
that). Obviously, if 4 reports were executed simultaneously and you had
4 CPUs on the server, they could be running on different CPUs.
If you have concerns, I guess you could leave the option on, but I would
suggest you test with the default settings as well.
David Gugick
Imceda Software
www.imceda.comsql

Parallel vs. serial plan

Hi,
What would be the advantages of lengthy report parallel vs.
serial execution, say on a 4-way SMP system, if the query
in itself is not able to produce sustained load of more
than 4 seconds on a single CPU of the system. I'm using MS
SQL Server 2000 on MS Windows 2000 with the lastest service
packs.
Many thanks,
Osk
Osk wrote:
> Hi,
> What would be the advantages of lengthy report parallel vs.
> serial execution, say on a 4-way SMP system, if the query
> in itself is not able to produce sustained load of more
> than 4 seconds on a single CPU of the system. I'm using MS
> SQL Server 2000 on MS Windows 2000 with the lastest service
> packs.
I would say that 4 seconds is a long time in the CPU world. It may not
be an issue if this is run off-hours, but during production hours, if
run many times, it could be more of an issue. Parallel executions
generally consume more CPU than their single-CPU brothers. It's just
more costly to manage parallel executions. So in your case, you are
potentially tying up one CPU out of four for four seconds, leaving the
other three to perform other tasks. With a parallel plan, depending on
how many CPUs SQL Server chooses to use, you'd end up tying up more CPU
for more than four CPU seconds, but the query could finish in 2.5
seconds.
Are you saying you have disabled parallel plans for this query using a
MAXDOP hint or have changed the corresponding server setting to prevent
parallel executions?
David Gugick
Imceda Software
www.imceda.com
|||SQL-Server does not know how important a particular query is for you. It
doesn't discriminate queries that way. It just estimates (for each
query) whether executing the parallel plan is likely to be faster than
the serial plan. If it is, and the server is not too stressed, then it
will execute the parallel plan. Otherwise, it will execute the serial
plan.
However, there is a threshold below which a parallel plan will not be
considered. By default, this "cost threshold for parallelism" is set to
5. With this setting, SQL-Server will not consider a parallel plan if
the estimated execution time of the serial plan is less than 5 seconds.
Hope this helps,
Gert-Jan
Osk wrote:
> Hi,
> What would be the advantages of lengthy report parallel vs.
> serial execution, say on a 4-way SMP system, if the query
> in itself is not able to produce sustained load of more
> than 4 seconds on a single CPU of the system. I'm using MS
> SQL Server 2000 on MS Windows 2000 with the lastest service
> packs.
> --
> Many thanks,
> Osk
|||Yes, I have changed the 'max degree of parallelism' server
setting to 1. So as I understand it now, when the optimizer
thinks the query can benefit from executing in parllel at
the same time when the rest of CPUs are more or less idle
then, despite the parallel plan being more costly in terms
of CPU time, the query will return results faster. So I
need look at what kind of load is placed on the rest of
CPUs during the time the query runs to determine whether
there will be any benefit or parallelism.

>--Original Message--
>Osk wrote:
>I would say that 4 seconds is a long time in the CPU
world. It may not
>be an issue if this is run off-hours, but during
production hours, if
>run many times, it could be more of an issue. Parallel
executions
>generally consume more CPU than their single-CPU brothers.
It's just
>more costly to manage parallel executions. So in your
case, you are
>potentially tying up one CPU out of four for four seconds,
leaving the
>other three to perform other tasks. With a parallel plan,
depending on
>how many CPUs SQL Server chooses to use, you'd end up
tying up more CPU
>for more than four CPU seconds, but the query could finish
in 2.5
>seconds.
>Are you saying you have disabled parallel plans for this
query using a
>MAXDOP hint or have changed the corresponding server
setting to prevent
>parallel executions?
>--
>David Gugick
>Imceda Software
>www.imceda.com
>.
>
|||anonymous@.discussions.microsoft.com wrote:
> Yes, I have changed the 'max degree of parallelism' server
> setting to 1. So as I understand it now, when the optimizer
> thinks the query can benefit from executing in parllel at
> the same time when the rest of CPUs are more or less idle
> then, despite the parallel plan being more costly in terms
> of CPU time, the query will return results faster. So I
> need look at what kind of load is placed on the rest of
> CPUs during the time the query runs to determine whether
> there will be any benefit or parallelism.
>
I thik you might be overthinking this a bit. Why have you decided to
change the MAX DEGREE OF PARALLELISM on the server and not let SQL
Server manage parallel queries on its own? Occasionally, someone reports
an issue with a parallel plan which can be easily fixed with a MAXDOP
(1) in the query.
David Gugick
Imceda Software
www.imceda.com
|||Well, that's how I understood it. If I'm wrong please
correct me.
I've set the server-wide MAXDOP to 1 because of two reasons:
1) to see whether placing the load of reports on a single
CPU will allow smaller queries have fulfilled their CPU
needs quicker than when they would have to wait for a
report to execute in parallel on all CPUs (although this
seems to work only in cases when the report doesn't hold
locks incompatible with other query's locks)
2) I can't provide hints at the T-SQL level yet
Thanks,
Osk

>--Original Message--
>anonymous@.discussions.microsoft.com wrote:
>I thik you might be overthinking this a bit. Why have you
decided to
>change the MAX DEGREE OF PARALLELISM on the server and not
let SQL
>Server manage parallel queries on its own? Occasionally,
someone reports
>an issue with a parallel plan which can be easily fixed
with a MAXDOP
>(1) in the query.
>--
>David Gugick
>Imceda Software
>www.imceda.com
>.
>
|||Osk wrote:
> Well, that's how I understood it. If I'm wrong please
> correct me.
> I've set the server-wide MAXDOP to 1 because of two reasons:
> 1) to see whether placing the load of reports on a single
> CPU will allow smaller queries have fulfilled their CPU
> needs quicker than when they would have to wait for a
> report to execute in parallel on all CPUs (although this
> seems to work only in cases when the report doesn't hold
> locks incompatible with other query's locks)
> 2) I can't provide hints at the T-SQL level yet
>
MAXDOP at the server level does not mean that reports are only going to
run on a single CPU. Unless what you're saying is that only one report
can run at a time and because of that it will only run on a single CPU.
MAXDOP 1 just means SQL Server will only use a single CPU for a query,
but the CPU used could be any available (maybe you already understood
that). Obviously, if 4 reports were executed simultaneously and you had
4 CPUs on the server, they could be running on different CPUs.
If you have concerns, I guess you could leave the option on, but I would
suggest you test with the default settings as well.
David Gugick
Imceda Software
www.imceda.com

Parallel vs. serial plan

Hi,
What would be the advantages of lengthy report parallel vs.
serial execution, say on a 4-way SMP system, if the query
in itself is not able to produce sustained load of more
than 4 seconds on a single CPU of the system. I'm using MS
SQL Server 2000 on MS Windows 2000 with the lastest service
packs.
--
Many thanks,
OskOsk wrote:
> Hi,
> What would be the advantages of lengthy report parallel vs.
> serial execution, say on a 4-way SMP system, if the query
> in itself is not able to produce sustained load of more
> than 4 seconds on a single CPU of the system. I'm using MS
> SQL Server 2000 on MS Windows 2000 with the lastest service
> packs.
I would say that 4 seconds is a long time in the CPU world. It may not
be an issue if this is run off-hours, but during production hours, if
run many times, it could be more of an issue. Parallel executions
generally consume more CPU than their single-CPU brothers. It's just
more costly to manage parallel executions. So in your case, you are
potentially tying up one CPU out of four for four seconds, leaving the
other three to perform other tasks. With a parallel plan, depending on
how many CPUs SQL Server chooses to use, you'd end up tying up more CPU
for more than four CPU seconds, but the query could finish in 2.5
seconds.
Are you saying you have disabled parallel plans for this query using a
MAXDOP hint or have changed the corresponding server setting to prevent
parallel executions?
--
David Gugick
Imceda Software
www.imceda.com|||SQL-Server does not know how important a particular query is for you. It
doesn't discriminate queries that way. It just estimates (for each
query) whether executing the parallel plan is likely to be faster than
the serial plan. If it is, and the server is not too stressed, then it
will execute the parallel plan. Otherwise, it will execute the serial
plan.
However, there is a threshold below which a parallel plan will not be
considered. By default, this "cost threshold for parallelism" is set to
5. With this setting, SQL-Server will not consider a parallel plan if
the estimated execution time of the serial plan is less than 5 seconds.
Hope this helps,
Gert-Jan
Osk wrote:
> Hi,
> What would be the advantages of lengthy report parallel vs.
> serial execution, say on a 4-way SMP system, if the query
> in itself is not able to produce sustained load of more
> than 4 seconds on a single CPU of the system. I'm using MS
> SQL Server 2000 on MS Windows 2000 with the lastest service
> packs.
> --
> Many thanks,
> Osk|||Yes, I have changed the 'max degree of parallelism' server
setting to 1. So as I understand it now, when the optimizer
thinks the query can benefit from executing in parllel at
the same time when the rest of CPUs are more or less idle
then, despite the parallel plan being more costly in terms
of CPU time, the query will return results faster. So I
need look at what kind of load is placed on the rest of
CPUs during the time the query runs to determine whether
there will be any benefit or parallelism.
>--Original Message--
>Osk wrote:
>> Hi,
>> What would be the advantages of lengthy report parallel vs.
>> serial execution, say on a 4-way SMP system, if the query
>> in itself is not able to produce sustained load of more
>> than 4 seconds on a single CPU of the system. I'm using MS
>> SQL Server 2000 on MS Windows 2000 with the lastest service
>> packs.
>I would say that 4 seconds is a long time in the CPU
world. It may not
>be an issue if this is run off-hours, but during
production hours, if
>run many times, it could be more of an issue. Parallel
executions
>generally consume more CPU than their single-CPU brothers.
It's just
>more costly to manage parallel executions. So in your
case, you are
>potentially tying up one CPU out of four for four seconds,
leaving the
>other three to perform other tasks. With a parallel plan,
depending on
>how many CPUs SQL Server chooses to use, you'd end up
tying up more CPU
>for more than four CPU seconds, but the query could finish
in 2.5
>seconds.
>Are you saying you have disabled parallel plans for this
query using a
>MAXDOP hint or have changed the corresponding server
setting to prevent
>parallel executions?
>--
>David Gugick
>Imceda Software
>www.imceda.com
>.
>|||anonymous@.discussions.microsoft.com wrote:
> Yes, I have changed the 'max degree of parallelism' server
> setting to 1. So as I understand it now, when the optimizer
> thinks the query can benefit from executing in parllel at
> the same time when the rest of CPUs are more or less idle
> then, despite the parallel plan being more costly in terms
> of CPU time, the query will return results faster. So I
> need look at what kind of load is placed on the rest of
> CPUs during the time the query runs to determine whether
> there will be any benefit or parallelism.
>
I thik you might be overthinking this a bit. Why have you decided to
change the MAX DEGREE OF PARALLELISM on the server and not let SQL
Server manage parallel queries on its own? Occasionally, someone reports
an issue with a parallel plan which can be easily fixed with a MAXDOP
(1) in the query.
--
David Gugick
Imceda Software
www.imceda.com|||Well, that's how I understood it. If I'm wrong please
correct me.
I've set the server-wide MAXDOP to 1 because of two reasons:
1) to see whether placing the load of reports on a single
CPU will allow smaller queries have fulfilled their CPU
needs quicker than when they would have to wait for a
report to execute in parallel on all CPUs (although this
seems to work only in cases when the report doesn't hold
locks incompatible with other query's locks)
2) I can't provide hints at the T-SQL level yet
--
Thanks,
Osk
>--Original Message--
>anonymous@.discussions.microsoft.com wrote:
>> Yes, I have changed the 'max degree of parallelism' server
>> setting to 1. So as I understand it now, when the optimizer
>> thinks the query can benefit from executing in parllel at
>> the same time when the rest of CPUs are more or less idle
>> then, despite the parallel plan being more costly in terms
>> of CPU time, the query will return results faster. So I
>> need look at what kind of load is placed on the rest of
>> CPUs during the time the query runs to determine whether
>> there will be any benefit or parallelism.
>I thik you might be overthinking this a bit. Why have you
decided to
>change the MAX DEGREE OF PARALLELISM on the server and not
let SQL
>Server manage parallel queries on its own? Occasionally,
someone reports
>an issue with a parallel plan which can be easily fixed
with a MAXDOP
>(1) in the query.
>--
>David Gugick
>Imceda Software
>www.imceda.com
>.
>|||Osk wrote:
> Well, that's how I understood it. If I'm wrong please
> correct me.
> I've set the server-wide MAXDOP to 1 because of two reasons:
> 1) to see whether placing the load of reports on a single
> CPU will allow smaller queries have fulfilled their CPU
> needs quicker than when they would have to wait for a
> report to execute in parallel on all CPUs (although this
> seems to work only in cases when the report doesn't hold
> locks incompatible with other query's locks)
> 2) I can't provide hints at the T-SQL level yet
>
MAXDOP at the server level does not mean that reports are only going to
run on a single CPU. Unless what you're saying is that only one report
can run at a time and because of that it will only run on a single CPU.
MAXDOP 1 just means SQL Server will only use a single CPU for a query,
but the CPU used could be any available (maybe you already understood
that). Obviously, if 4 reports were executed simultaneously and you had
4 CPUs on the server, they could be running on different CPUs.
If you have concerns, I guess you could leave the option on, but I would
suggest you test with the default settings as well.
David Gugick
Imceda Software
www.imceda.com

Paradox, ObjectPAL, MS SQL 2000

Hi!
My company implemented an in-house computer system that links up the work of
all major departments 10 years ago, using Paradox. Currently, we are still
using Paradox 10, and we are thinking of migrating to MS SQL 2000 server.
Is there any way to export the Paradox tables to the MS SQL 2000 server,
while continue using the ObjectPAL codings that we have already developed?
That is, using ObjectPAL to interact with the MS SQL table, instead of
Paradox table. Is there such a way? Otherwise, if we re-do all the codings in
Visual Basic, or other languages, it would be tedious. Or is there any way to
convert the ObjectPAL codings to other languages that support MS SQL?
Please advise.
Thank you.
I've found out the way to connect to the MS SQL 2000 server using Paradox. I
just define a new alias first, and connect to it and perform a executeSQL
statement, which can allow me to interact with the tables in the SQL 2000
server. But there's an issue, would it then not be storing real-time
information in the server unless the user press a Save button, or something
like that in the interface? Won't this result a lot of other problems like
inconsistency, concurrency and etc?
"wrytat" wrote:

> Hi!
> My company implemented an in-house computer system that links up the work of
> all major departments 10 years ago, using Paradox. Currently, we are still
> using Paradox 10, and we are thinking of migrating to MS SQL 2000 server.
> Is there any way to export the Paradox tables to the MS SQL 2000 server,
> while continue using the ObjectPAL codings that we have already developed?
> That is, using ObjectPAL to interact with the MS SQL table, instead of
> Paradox table. Is there such a way? Otherwise, if we re-do all the codings in
> Visual Basic, or other languages, it would be tedious. Or is there any way to
> convert the ObjectPAL codings to other languages that support MS SQL?
> Please advise.
> Thank you.

Paradox, ObjectPAL, MS SQL 2000

Hi!
My company implemented an in-house computer system that links up the work of
all major departments 10 years ago, using Paradox. Currently, we are still
using Paradox 10, and we are thinking of migrating to MS SQL 2000 server.
Is there any way to export the Paradox tables to the MS SQL 2000 server,
while continue using the ObjectPAL codings that we have already developed?
That is, using ObjectPAL to interact with the MS SQL table, instead of
Paradox table. Is there such a way? Otherwise, if we re-do all the codings in
Visual Basic, or other languages, it would be tedious. Or is there any way to
convert the ObjectPAL codings to other languages that support MS SQL?
Please advise.
Thank you.I've found out the way to connect to the MS SQL 2000 server using Paradox. I
just define a new alias first, and connect to it and perform a executeSQL
statement, which can allow me to interact with the tables in the SQL 2000
server. But there's an issue, would it then not be storing real-time
information in the server unless the user press a Save button, or something
like that in the interface? Won't this result a lot of other problems like
inconsistency, concurrency and etc?
"wrytat" wrote:
> Hi!
> My company implemented an in-house computer system that links up the work of
> all major departments 10 years ago, using Paradox. Currently, we are still
> using Paradox 10, and we are thinking of migrating to MS SQL 2000 server.
> Is there any way to export the Paradox tables to the MS SQL 2000 server,
> while continue using the ObjectPAL codings that we have already developed?
> That is, using ObjectPAL to interact with the MS SQL table, instead of
> Paradox table. Is there such a way? Otherwise, if we re-do all the codings in
> Visual Basic, or other languages, it would be tedious. Or is there any way to
> convert the ObjectPAL codings to other languages that support MS SQL?
> Please advise.
> Thank you.

Paradox, ObjectPAL, MS SQL 2000

Hi!
My company implemented an in-house computer system that links up the work of
all major departments 10 years ago, using Paradox. Currently, we are still
using Paradox 10, and we are thinking of migrating to MS SQL 2000 server.
Is there any way to export the Paradox tables to the MS SQL 2000 server,
while continue using the ObjectPAL codings that we have already developed?
That is, using ObjectPAL to interact with the MS SQL table, instead of
Paradox table. Is there such a way? Otherwise, if we re-do all the codings i
n
Visual Basic, or other languages, it would be tedious. Or is there any way t
o
convert the ObjectPAL codings to other languages that support MS SQL?
Please advise.
Thank you.I've found out the way to connect to the MS SQL 2000 server using Paradox. I
just define a new alias first, and connect to it and perform a executeSQL
statement, which can allow me to interact with the tables in the SQL 2000
server. But there's an issue, would it then not be storing real-time
information in the server unless the user press a Save button, or something
like that in the interface? Won't this result a lot of other problems like
inconsistency, concurrency and etc?
"wrytat" wrote:

> Hi!
> My company implemented an in-house computer system that links up the work
of
> all major departments 10 years ago, using Paradox. Currently, we are still
> using Paradox 10, and we are thinking of migrating to MS SQL 2000 server.
> Is there any way to export the Paradox tables to the MS SQL 2000 server,
> while continue using the ObjectPAL codings that we have already developed?
> That is, using ObjectPAL to interact with the MS SQL table, instead of
> Paradox table. Is there such a way? Otherwise, if we re-do all the codings
in
> Visual Basic, or other languages, it would be tedious. Or is there any way
to
> convert the ObjectPAL codings to other languages that support MS SQL?
> Please advise.
> Thank you.

Pagination for Large data

I want to build a system that will have about 1 million rows in a
table in sql server database.I am using this for a web application and
accessing it via JDBC type 4 driver.But display 20 records at a time
only using pagination(as in google).What will be the best way to go
about this.On 10 Oct 2003 04:04:11 -0700, nik_sharma75@.hotmail.com (Nikhil
Sharma) wrote:

>I want to build a system that will have about 1 million rows in a
>table in sql server database.I am using this for a web application and
>accessing it via JDBC type 4 driver.But display 20 records at a time
>only using pagination(as in google).What will be the best way to go
>about this.

Figure how many anyone is actually ever going to page through.
Obviously no one is going to page through to the end. How many google
pages would you look at before refining your search? Then construct
your query and restrict it with TOP. Cache the results and handle the
paging in your app.

Page Not Found, Sort Of

System: Win2k3, SQL2k5, Sharepoint (all on same box)
Note: default website port is 8000 (I mentioned this because it's non
standard)
I had this system all setup and running properly then all of the sudden
some brilliant support person at our data center decided to change the
I.P. of the server. This wreaked havoc on most of the code on that box
as I had to change all of the config files, DNS, and HTTP headers.
I finally got most of the pieces running again, but I have a couple an
issue. Currently there are two instances of SSRS running on the box. I
have the "old" one's service stopped, so it is not running, but when
browsing to http://localhost:8000/reports it is still trying to go to
the stopped instance. How can I change that? I've tried the rsconfig
utility, but I may not have the correct parameters.
thanks,
.britOh, one more thing. The "Page Not Found" error mentioned in the subject
refers to a very strange problem that I feel is resulting from having
two instances of SSRS running.
I have a domain name pointing to the default IP for the box. If I use
[domain url]/reports everything works great in Report Manager until I
actually go to view a report and then I get a Page Not Found error
within Report Manager. The error does not take over the entire screen,
just the portion in Rpt Mgr that would show the report.
If I go straight to the report using [domain url]/reportserver/[path of
report] they work great.
What gives?
thanks,
.brit