BAQ difference in Pilot compared to LIVE

Kinetic ERP
41

Bryan Cranston Mic Drop GIF

42

What is the best way to delete this?

43

Deleting the record is just covering up the problem. Ultimately, you need to make sure your query can handle that if it ever comes up. Which you may have done in your changes that you made. I couldn’t really follow exactly what was done to know for sure that it solved it.

You now know how to use the tryparse() function to convert to integers, so that should help you.

44

are there several companies in the DB? there is still a record with “UserID” text somewhere

45

Brandon,
I agree that deleting the data is just covering it up, but it is not a valid line of data. do you have any tips on how to delete it? When I look at DMT for Task, I struggle to find the unique identifiers to delete this specific record.

Olga,
There are 3 companies in the database.

46

It’s his UserID! I didn’t quite understand what he meant by the phrase. The error had his userID in the error. That’s the problem.

47

Yes, Key1 is normally the Quote number and somehow my userID fell into that column for this record. It is bad data and I want to delete it.

48

Look at the RelatedToFile (field) in the Task table I suspect that this is a record not related to a quote but to a different task.

Tasks in Epicor are used by many systems, cases, expenses, you name it.

I suspect that is indeed a valid a record (look at the RelatatedToFile field) it just ins’t valid for a quote. You should limit your query to filter that Task table on RelatedToFile =‘QuoteHed’ (on top of all other suggestions here)

49

Related to file is “person”

50

There you go, somehow (someone) entered a task in CRM related to a Person and that’s how that task was created. That is a VALID epicor record, it is your job to remove it from your query by using a filter in RelatedToFile.

There are lots and lots of records like this in epicor one of them being the attachment table (there’s an open letter I penned regarding these “generic” records somewhere around here that is pretty amusing) but regardless this is a valid record that you should not delete.

51

then you probably should check in all of them. SQL server does not care about company boundaries when it scans the table and stumble across incorrect data

52

The other two companies do not have any Key1 entries that are not integers.

This record was a mistake entry. When I try to delete it, I get this? Is there any way to force remove this record?
image

53

You can’t delete tasks directly, you need to delete what it’s related to…

That being said, this isn’t the solution to your problem. So don’t worry about deleting it.

54

Leave it alone it affects nothing don’t try to delete records out of the data / database just walk away.

55

Another food for thought… Task is a silly table in that it has Company, RelatedToFile, Key1, Key2, Key3 and maybe TaskSeqNum also as keys for uniqueness. If the join were done with RelatedToFile = ‘QuoteHed’ along with the Key1, it likely would’ve worked with Key1 being converted/parsed to an int. But for Task table especially, there’s usually a column or multiple columns that identify the thing it’s related to in the format that it needs to be for a join. Not sure if joining using a non-indexed column performs worse than joining using a converted key, but I’ve never needed to know that up until now. I’d be curious if anyone knows.

56

That is what execution plans are for. But I am not sure if it is available when query fails.