32 bit XPs on 64bit?

We've got two Extended Proceedures that work fine on 32bit, no bugs and
never AVed the server.
We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
2005 64bit.
Will these 32bit XPs work fine without change in SQL 64? Or will a simple
recompile with a 64bit compiler make it work in SQL 64bit?
Yeah Yeah Yeah, I know all about CLR in Yukon, I'm not asking that question!"Bud Y. Zer" <bud@.Gibralter.Bra> wrote in message
news:%23$8V4LzrFHA.248@.TK2MSFTNGP14.phx.gbl...
> We've got two Extended Proceedures that work fine on 32bit, no bugs and
> never AVed the server.
> We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
> 2005 64bit.
> Will these 32bit XPs work fine without change in SQL 64?
No. Extended stored procedures are dll's loaded into the SQL Server process,
and a 64bit process can only load 64bit dll's.

>Or will a simple recompile with a 64bit compiler make it work in SQL
>64bit?
It depends on how the dll's are written.
See generally,
http://msdn.microsoft.com/isv/techn...l
t.aspx
There are things you can do in C++ which implicity rely on pointers being
32bits.
David

32 bit XPs on 64bit?

We've got two Extended Proceedures that work fine on 32bit, no bugs and
never AVed the server.
We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
2005 64bit.
Will these 32bit XPs work fine without change in SQL 64? Or will a simple
recompile with a 64bit compiler make it work in SQL 64bit?
Yeah Yeah Yeah, I know all about CLR in Yukon, I'm not asking that question!
"Bud Y. Zer" <bud@.Gibralter.Bra> wrote in message
news:%23$8V4LzrFHA.248@.TK2MSFTNGP14.phx.gbl...
> We've got two Extended Proceedures that work fine on 32bit, no bugs and
> never AVed the server.
> We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
> 2005 64bit.
> Will these 32bit XPs work fine without change in SQL 64?
No. Extended stored procedures are dll's loaded into the SQL Server process,
and a 64bit process can only load 64bit dll's.

>Or will a simple recompile with a 64bit compiler make it work in SQL
>64bit?
It depends on how the dll's are written.
See generally,
http://msdn.microsoft.com/isv/techno...q/default.aspx
There are things you can do in C++ which implicity rely on pointers being
32bits.
David

32 bit XPs on 64bit?

We've got two Extended Proceedures that work fine on 32bit, no bugs and
never AVed the server.
We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
2005 64bit.
Will these 32bit XPs work fine without change in SQL 64? Or will a simple
recompile with a 64bit compiler make it work in SQL 64bit?
Yeah Yeah Yeah, I know all about CLR in Yukon, I'm not asking that question!"Bud Y. Zer" <bud@.Gibralter.Bra> wrote in message
news:%23$8V4LzrFHA.248@.TK2MSFTNGP14.phx.gbl...
> We've got two Extended Proceedures that work fine on 32bit, no bugs and
> never AVed the server.
> We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
> 2005 64bit.
> Will these 32bit XPs work fine without change in SQL 64?
No. Extended stored procedures are dll's loaded into the SQL Server process,
and a 64bit process can only load 64bit dll's.
>Or will a simple recompile with a 64bit compiler make it work in SQL
>64bit?
It depends on how the dll's are written.
See generally,
http://msdn.microsoft.com/isv/technology/64bitwindows/x64faq/developmentfaq/default.aspx
There are things you can do in C++ which implicity rely on pointers being
32bits.
David

3 Management Studio Bugs

Good morning,
If this is the wrong place to post this I apologize, but I haven't been able to find any forums dedicated specifically to SQL Server 2005.
I've posted 3 bugs to the MSDN Feedback Center, which have yet to be "validated". As I understand it, nobody from MS even looks at the issue unless another user has seconded the nomination, so to speak. And the only way that happens is if someone happens to search for the same issue.
At this point I realize it's probably too close to release date and none of these will be fixed until later, but I would still like some confirmation before I waste any more time reporting issues. If you have the time, please take a look:
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=65d3204e-e17b-4974-96ed-f583f2eec433
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=a4216d4a-7523-49bf-838b-87900455c7f5
http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=4f72eb5a-ef83-4fdc-8482-2f191fcd2c5e
All three are relatively minor annoyances with Management Studio, they are quick and easy to reproduce.
Thanks,
Chris

Hi Chris, I looked at your three bugs. The first one about the space bar and Shift, I'm not sure of, I'll have to let the UI folks figure that one out.

The second one with the temp table, this is by design. TRY/CATCH errors do not trap syntax errors. This is documented in Books Online. So in your case, the temp table was created, then the batch file exited after the parsing error. When you fixed the column name and ran it again, the TRY/CATCH was invoked because you were trying to create a temp table again with the same name, but it existed. Since this is an execution error, it dropped down to the catch and dropped the table. Since a "DROP TABLE" does not have any results, and since it was the only command executed, there is no reason to display the RESULTS pane. What you can do is run this in Profiler and you will see the exact statements being executed.

For the third one, about the renaming of a job, this doesn't repro on the RTM version.

Hope this helps.|||Thanks for taking the time to review them