Hi all! I am trying to do a cleanup of all of our workers by making around ~175 of them inactive, and as a beginner SQL user I'd appreciate the community's review/advice on my code.
Here is what I'm trying to update on these constituent records:
And I have a static list of all of the workers that need to be made inactive (list # 133113).
So the SQL script I came up with is as follows:
Use impresarioselect *from T_LIST_CONTENTS a left outer join TX_CUST_WORKER_TYPE bon a.customer_no=b.worker_customer_nowhere a.list_no='133113' and b.inactive = 'n'
--below is a separate part of the code to run. begin transactionupdate TX_CUST_WORKER_TYPEset inactive = 'y'where worker_customer_no in (select b.worker_customer_no from T_LIST_CONTENTS aleft outer join TX_CUST_WORKER_TYPE b on a.customer_no=b.worker_customer_nowhere a.list_no='133113') commit
I tried this in Test, but I must have done something wrong; afterwards, opening any of the affected accounts would cause Test to crash. (I did a Prod to Test copy last night, so Test is now working properly again).
Many thanks in advance for any tips or advice!
Liz
Elizabeth Marvin,
Hello from slightly to the north of you! T.C. Brown is correct, I believe. I just ran your script against an isolated worker in our own TEST database with the capital 'Y' (always recommended, though sometimes it should not matter, on single character things like this, I always make sure to mimic what is already being done), and everything worked just fine for me.
If not that, there might be something else in play here.
John A. Moskal II
That's fascinating, as SQL Server SQL is supposed to be case insensitive by default.
Supposed to be. But I have found some select instances where supposed to be cannot be counted upon like it is supposed to be. When in doubt, always copy what has already been done, as we know well.
SQL Server is, but Sybase may not be. That screen is evaluating a dataset, and it must care about case.
I bet you are right. The application interface itself might be the thing causing the issue, not the database. One also would have thought that if it were an issue, that her initial UPDATE statement would have failed in SSMS when she tried to run it the first time, and it does not appear to have done so, only when she tried to open the application.