Thursday, March 8, 2012

Copy current record (again)

Hi there,
What I have is an appointments diary, what I want is to be able to move
details from one record to another (when someone calls to move their
appointment from one day & time to another).
Tablename: AppDetails includes the following fields:
Appdate smalldatetime (PK)
Apptime varchar(!) 10 (PK) - this not one of my tables!
Appname varchar 100
Address1....Address3 all varchar 100
Postcode varchar 20
The table is filled with 24 times (9.00am, 9.30am...8.30pm) per date over
ten years!
The user sees one record to view and what I'd like is an sp to copy all the
values in the visible record (not Appdate or Apptime) into @.Variables that
could be called from a button and another to paste them onto the new record
(the user will select the new record).
Where I'm stuck is how to select the Current record.
Help please
Thanks
Paul> Where I'm stuck is how to select the Current record.
You select a row by it's *Key*. As far as SQL is concerned there is no
such thing as a "current record" - it is your client app's job to pass
the key back to SQL Server.
How does this question differ from the one you asked last w?
http://www.google.co.uk/groups?selm...r />
roups.com
You're likely to get more help if you follow the suggestion I made then
about posting full details.
David Portas
SQL Server MVP
--|||Sounds like an ideal question for Joe to reply ;)
Roji. P. Thomas
Net Asset Management
https://www.netassetmanagement.com
"Paul in Harrow" <PaulinHarrow@.discussions.microsoft.com> wrote in message
news:7BF7D25A-2BBE-4942-8921-2A6E4FFF83E0@.microsoft.com...
> Hi there,
> What I have is an appointments diary, what I want is to be able to move
> details from one record to another (when someone calls to move their
> appointment from one day & time to another).
> Tablename: AppDetails includes the following fields:
> Appdate smalldatetime (PK)
> Apptime varchar(!) 10 (PK) - this not one of my tables!
> Appname varchar 100
> Address1....Address3 all varchar 100
> Postcode varchar 20
> The table is filled with 24 times (9.00am, 9.30am...8.30pm) per date over
> ten years!
> The user sees one record to view and what I'd like is an sp to copy all
> the
> values in the visible record (not Appdate or Apptime) into @.Variables that
> could be called from a button and another to paste them onto the new
> record
> (the user will select the new record).
> Where I'm stuck is how to select the Current record.
> Help please
> Thanks
> Paul
>|||"David Portas" wrote:

> You select a row by it's *Key*. As far as SQL is concerned there is no
> such thing as a "current record" - it is your client app's job to pass
> the key back to SQL Server.
> How does this question differ from the one you asked last w?
It's the same question but I've finally got some some time to work on it.
Thanks
Paul|||Then, just to re-iterate: SQL knows nothing about what row is "current"
within your application. I imagine the logical sequence will be:
1. User chooses an appointment time.
2. User selects "copy". Application saves data for the row or just the
key values for the row.
3. User chooses a new appointment time.
4. User selects "paste". Application updates the table based on the key
values of the new row (@.ad2 and @.at2 in my original example) and the
data saved in Step 2.
Step 4 is the only SQL data modification operation.
David Portas
SQL Server MVP
--|||"David Portas" wrote:
> Then, just to re-iterate: SQL knows nothing about what row is "current"
> within your application. I imagine the logical sequence will be:
> 1. User chooses an appointment time.
> 2. User selects "copy". Application saves data for the row or just the
> key values for the row.
> 3. User chooses a new appointment time.
> 4. User selects "paste". Application updates the table based on the key
> values of the new row (@.ad2 and @.at2 in my original example) and the
> data saved in Step 2.
Spot on
I've been trying to avoid doing any of this with the front end app as it's
sooo slow.

> Step 4 is the only SQL data modification operation.
Many thanks for your help
Paul

No comments:

Post a Comment