I'm using SQLServer2000/Access 2000 .adp. The .adp has a form with 2 combo boxes. The 1st combo box is bound to a stored procedure and loads fine when the form loads. I then set the 2nd combo box's RowSource passing the value of the first into the stored proc:
Me.secondComboBox.RowSource = "EXEC dbo.proc_My2ndProc '" & Me.cboFirstComboBox & "'"
Me.cbosecondComboBox.reQuery
Why won't it work? I've set a form's RecordSource using this methof, and it works great?
Thanks,
CarlDummy me, I didn't have the RowSourceType set to Table/View/StoredProc, all's well. I figured it out by creating a new form, and it was working, so I went to see what was different.
Showing posts with label populate. Show all posts
Showing posts with label populate. Show all posts
Sunday, March 25, 2012
Thursday, March 22, 2012
Access ADP,Server 2000, inconsistent behavior with output paramete
I am getting inconsistent responses from SQL Server 2000 and do not know why
.
I populate the controls on an unbound form by executing a command object tha
t
calls a sproc that returns a recordset.
On SQL Server 2000 the srpoc returns the recordset used to fill the form's
controls plus an output parameter indicating a record was received. The
output parameter is the value of @.@.ROWCOUNT. If the value of the output
parameter = 0, the user gets an appropriate message concerning the failure t
o
retrieve the data.
The server on my desktop returns both the recordset for populating the form
and the value of @.@.ROWCOUNT from the database. No problem.
However, when I connect to an identical dataase on a server in Chicago using
a VPN, all I get back is the recordset. The value of the output parameter is
always zero, telling me no record was selected.
However, the record was selected as the data populates the form.
I can easily branch to the needed message using "If rst.BOF and rst.EOF
then..." but I'd like to know why the output parameter does not get returned
or is always zero when I use the VPN to connect to the database.
If I use a command object to execute a sproc that does not return a
recordset, I do get back any desired output parameters. This inconsistent
behavior only appears when the executed command object returns a recordset.
Is there a setting on the Chicago server causing the problem?
malcolmHow are you sure that these two databases are really identical?
One possibility would be that the server in Chicago has a different order
for fields inside a table. This could cause some trouble with ADP is you are
using things like Select * instead of Select field1, field2, ... .
When you change the connection, the Tables and the Views/SP/Functions
windows should be refreshed but we never know what may have happened. One
way to be sure would be to use the Refresh command for *BOTH* the Tables and
the Views/SP/Functions windows and/or to recompile the ADP file.
Another possibility would be a permission problem or a logon account that is
not mapped to the same role.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"malcolm" <ramartower@.access312.com> wrote in message
news:00FCB54F-AEA4-43EB-A712-3B6FC3B68DA5@.microsoft.com...
>I am getting inconsistent responses from SQL Server 2000 and do not know
>why.
> I populate the controls on an unbound form by executing a command object
> that
> calls a sproc that returns a recordset.
> On SQL Server 2000 the srpoc returns the recordset used to fill the form's
> controls plus an output parameter indicating a record was received. The
> output parameter is the value of @.@.ROWCOUNT. If the value of the output
> parameter = 0, the user gets an appropriate message concerning the failure
> to
> retrieve the data.
> The server on my desktop returns both the recordset for populating the
> form
> and the value of @.@.ROWCOUNT from the database. No problem.
> However, when I connect to an identical dataase on a server in Chicago
> using
> a VPN, all I get back is the recordset. The value of the output parameter
> is
> always zero, telling me no record was selected.
> However, the record was selected as the data populates the form.
> I can easily branch to the needed message using "If rst.BOF and rst.EOF
> then..." but I'd like to know why the output parameter does not get
> returned
> or is always zero when I use the VPN to connect to the database.
> If I use a command object to execute a sproc that does not return a
> recordset, I do get back any desired output parameters. This inconsistent
> behavior only appears when the executed command object returns a
> recordset.
> Is there a setting on the Chicago server causing the problem?
> --
> malcolm
.
I populate the controls on an unbound form by executing a command object tha
t
calls a sproc that returns a recordset.
On SQL Server 2000 the srpoc returns the recordset used to fill the form's
controls plus an output parameter indicating a record was received. The
output parameter is the value of @.@.ROWCOUNT. If the value of the output
parameter = 0, the user gets an appropriate message concerning the failure t
o
retrieve the data.
The server on my desktop returns both the recordset for populating the form
and the value of @.@.ROWCOUNT from the database. No problem.
However, when I connect to an identical dataase on a server in Chicago using
a VPN, all I get back is the recordset. The value of the output parameter is
always zero, telling me no record was selected.
However, the record was selected as the data populates the form.
I can easily branch to the needed message using "If rst.BOF and rst.EOF
then..." but I'd like to know why the output parameter does not get returned
or is always zero when I use the VPN to connect to the database.
If I use a command object to execute a sproc that does not return a
recordset, I do get back any desired output parameters. This inconsistent
behavior only appears when the executed command object returns a recordset.
Is there a setting on the Chicago server causing the problem?
malcolmHow are you sure that these two databases are really identical?
One possibility would be that the server in Chicago has a different order
for fields inside a table. This could cause some trouble with ADP is you are
using things like Select * instead of Select field1, field2, ... .
When you change the connection, the Tables and the Views/SP/Functions
windows should be refreshed but we never know what may have happened. One
way to be sure would be to use the Refresh command for *BOTH* the Tables and
the Views/SP/Functions windows and/or to recompile the ADP file.
Another possibility would be a permission problem or a logon account that is
not mapped to the same role.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF
"malcolm" <ramartower@.access312.com> wrote in message
news:00FCB54F-AEA4-43EB-A712-3B6FC3B68DA5@.microsoft.com...
>I am getting inconsistent responses from SQL Server 2000 and do not know
>why.
> I populate the controls on an unbound form by executing a command object
> that
> calls a sproc that returns a recordset.
> On SQL Server 2000 the srpoc returns the recordset used to fill the form's
> controls plus an output parameter indicating a record was received. The
> output parameter is the value of @.@.ROWCOUNT. If the value of the output
> parameter = 0, the user gets an appropriate message concerning the failure
> to
> retrieve the data.
> The server on my desktop returns both the recordset for populating the
> form
> and the value of @.@.ROWCOUNT from the database. No problem.
> However, when I connect to an identical dataase on a server in Chicago
> using
> a VPN, all I get back is the recordset. The value of the output parameter
> is
> always zero, telling me no record was selected.
> However, the record was selected as the data populates the form.
> I can easily branch to the needed message using "If rst.BOF and rst.EOF
> then..." but I'd like to know why the output parameter does not get
> returned
> or is always zero when I use the VPN to connect to the database.
> If I use a command object to execute a sproc that does not return a
> recordset, I do get back any desired output parameters. This inconsistent
> behavior only appears when the executed command object returns a
> recordset.
> Is there a setting on the Chicago server causing the problem?
> --
> malcolm
Monday, February 13, 2012
About implicit transactions in temp table
I have a .net program which usually create temp table in SQL Server 2005 and
populate it from com contrlol to apply later to the main table.But sometimes
I need to delete some of previously inserted rows to replace them with maybe
more and adjusted ones.
I did this by deleting suspicious rows and going back on com control to
inserting rows.
I did found that I am missing some rows.
It seems that deletion does not synchronized with consequenced insertions.
Is it neccessary to do explicit transaction or this is one of 2005
optimizations on temp tables?Hi
I am not really clear how you are doing this, maybe you would like to post
some sample code? If the com control has it's own connection then you may not
be using the same temporary table!
John
"UncleSam89" wrote:
> I have a .net program which usually create temp table in SQL Server 2005 and
> populate it from com contrlol to apply later to the main table.But sometimes
> I need to delete some of previously inserted rows to replace them with maybe
> more and adjusted ones.
> I did this by deleting suspicious rows and going back on com control to
> inserting rows.
> I did found that I am missing some rows.
> It seems that deletion does not synchronized with consequenced insertions.
> Is it neccessary to do explicit transaction or this is one of 2005
> optimizations on temp tables?|||It seems that it was my own bug
sorry
"John Bell" wrote:
> Hi
> I am not really clear how you are doing this, maybe you would like to post
> some sample code? If the com control has it's own connection then you may not
> be using the same temporary table!
> John
> "UncleSam89" wrote:
> > I have a .net program which usually create temp table in SQL Server 2005 and
> > populate it from com contrlol to apply later to the main table.But sometimes
> > I need to delete some of previously inserted rows to replace them with maybe
> > more and adjusted ones.
> > I did this by deleting suspicious rows and going back on com control to
> > inserting rows.
> > I did found that I am missing some rows.
> > It seems that deletion does not synchronized with consequenced insertions.
> > Is it neccessary to do explicit transaction or this is one of 2005
> > optimizations on temp tables?
populate it from com contrlol to apply later to the main table.But sometimes
I need to delete some of previously inserted rows to replace them with maybe
more and adjusted ones.
I did this by deleting suspicious rows and going back on com control to
inserting rows.
I did found that I am missing some rows.
It seems that deletion does not synchronized with consequenced insertions.
Is it neccessary to do explicit transaction or this is one of 2005
optimizations on temp tables?Hi
I am not really clear how you are doing this, maybe you would like to post
some sample code? If the com control has it's own connection then you may not
be using the same temporary table!
John
"UncleSam89" wrote:
> I have a .net program which usually create temp table in SQL Server 2005 and
> populate it from com contrlol to apply later to the main table.But sometimes
> I need to delete some of previously inserted rows to replace them with maybe
> more and adjusted ones.
> I did this by deleting suspicious rows and going back on com control to
> inserting rows.
> I did found that I am missing some rows.
> It seems that deletion does not synchronized with consequenced insertions.
> Is it neccessary to do explicit transaction or this is one of 2005
> optimizations on temp tables?|||It seems that it was my own bug
sorry
"John Bell" wrote:
> Hi
> I am not really clear how you are doing this, maybe you would like to post
> some sample code? If the com control has it's own connection then you may not
> be using the same temporary table!
> John
> "UncleSam89" wrote:
> > I have a .net program which usually create temp table in SQL Server 2005 and
> > populate it from com contrlol to apply later to the main table.But sometimes
> > I need to delete some of previously inserted rows to replace them with maybe
> > more and adjusted ones.
> > I did this by deleting suspicious rows and going back on com control to
> > inserting rows.
> > I did found that I am missing some rows.
> > It seems that deletion does not synchronized with consequenced insertions.
> > Is it neccessary to do explicit transaction or this is one of 2005
> > optimizations on temp tables?
Subscribe to:
Posts (Atom)