Stupid request of the day
-
Hey, if his live depends on it, I'm suggesting a solution. Actually it's not that bad. you can: select TableName, columnName from whatever joins you need to do on all columns that are text, varchar, nchar etc. Then you run select count(ColumnName) from TableName where columName like '%whatever you search%' Let's say 1-2 secs per query on a table up to 1 million records, he will have the answers in a hour or two. It's a ridiculous request, but you know, if he absolutely needs to do it ...
Bad Hombre wrote:
Actually it's not that bad.
Agreed, it is not 'that bad', but it is absolutely not what I want to hear from a specialist. Given the amount of data, and the type of request, and given that you have the freedom to make better suggestions, I'd expect one. Any decent database-operator will have a backup of anything on that server. Go search that and leave the production database alone. Ask where the customer "lost his G:", on which page, which application. Ask for a date-range. When did you have your G:? Ask whether it is actually feasible - in a database full with blobs you're bound to run into that combination, how do you know if it is the G: that the client is looking for, or just a random G:? Could it be in an encrypted or compacted field, and if so, do you want to search those too? Do you seriously need to search usernames and hash-columns, any logging-tables, if the customer cannot have lost his G: there?
Bad Hombre wrote:
It's a ridiculous request, but you know, if he absolutely needs to do it ...
Instead of doing something rediculous because you're simply told to do so, you could try and recognize a failure in communication and offer an intelligent alternative.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Time for the Wally Deflector... Dilbert Comic Strip on 2005-07-10 | Dilbert by Scott Adams[^]
-
Bad Hombre wrote:
Actually it's not that bad.
Agreed, it is not 'that bad', but it is absolutely not what I want to hear from a specialist. Given the amount of data, and the type of request, and given that you have the freedom to make better suggestions, I'd expect one. Any decent database-operator will have a backup of anything on that server. Go search that and leave the production database alone. Ask where the customer "lost his G:", on which page, which application. Ask for a date-range. When did you have your G:? Ask whether it is actually feasible - in a database full with blobs you're bound to run into that combination, how do you know if it is the G: that the client is looking for, or just a random G:? Could it be in an encrypted or compacted field, and if so, do you want to search those too? Do you seriously need to search usernames and hash-columns, any logging-tables, if the customer cannot have lost his G: there?
Bad Hombre wrote:
It's a ridiculous request, but you know, if he absolutely needs to do it ...
Instead of doing something rediculous because you're simply told to do so, you could try and recognize a failure in communication and offer an intelligent alternative.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
I said text columns, not varbinary. This pretty much excludes blobs, also you can exclude columns with max_length let's say 2000 characters. Edit: And I'm not a database operator, administrator or anything like that, just a lowly mobile developer, so I don't insist on having the perfect solution. :)
-
I said text columns, not varbinary. This pretty much excludes blobs, also you can exclude columns with max_length let's say 2000 characters. Edit: And I'm not a database operator, administrator or anything like that, just a lowly mobile developer, so I don't insist on having the perfect solution. :)
Bad Hombre wrote:
I said text columns, not varbinary. This pretty much excludes blobs, also you can exclude columns with max_length let's say 2000 characters.
You might be choosing to actually exclude the columns that are actually required. Without asking, one is just guessing.
Bad Hombre wrote:
Edit: And I'm not a database operator, administrator or anything like that, just a lowly mobile developer, so I don't insist on having the perfect solution.
Sometimes any solution is better than having nothing. There's no ranks here, so 'lowly' does not apply :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
The easiest way to solve this is to insert a new row into a table and have G: as part of the content for a column's data. Now answer "yes" and if he asks for the data, just send him the row you just inserted. You are welcome. :cool:
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
Elegance is simplicity. The perfect solution.
I wanna be a eunuchs developer! Pass me a bread knife!