7/8/2025 5:29:02 PM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss general administration topics for SalesLogix (including LAN & remote topics). View the code of conduct for posting guidelines.
|
|
|
|
Some tables in the DB
Posted: 16 Mar 07 7:03 PM
|
fiogf49gjkf0d I'm doing an analysis on a cleanup/archive/purge for my customer. I've used SQL Compare to compare a 6.2.6 DB with my customers DB to compare schema. I've found data in the collectiondefs table which doesn't exist in my 6.2.6 database, but does in my customer's DB, which started as a 5.2 database. What's odd is that the "builddate" in the table is 2006-03-31, which is the day we upgraded from 5.2 to 6.2.6. Am I correct in that:
1) The table was used with speedsearch in previous versions, and
2) it's not used now, and
3) I should be OK dropping it (I won't hold you to anything)
I know they're not using speedsearch, but I find it odd that the build date was 2006-03-31 in the table. I'm trying to figure out why it would have been updated if it's no longer used.
All the other "collectionxxxxx" tables are empty - I just found it odd the collectiondefs has values. Can anyone explain?
I have a few other tables that have data in them, but I'm not sure why. If anyone knows how they are/were used, feel free to share:
1) emailprofile (1 record)
2) ksync (They're not using KnowledgeSync)
3) ksync_rels (They're not using KnowledgeSync)
4) ksynctables (They're not using KnowledgeSync)
5) slxwebreport (They're not using web reporting, so this can probably go away)
6) useroption (Not to be confused with useroptionS. The record count is exactly the same as the slxwebreport table, making me think they're related.)
Thanks,
Jeff
|
|
|
|
Re: Some tables in the DB
Posted: 18 Mar 07 3:49 PM
|
fiogf49gjkf0d Originally posted by Jeff Ballard
I'm doing an analysis on a cleanup/archive/purge for my customer. I've used SQL Compare to compare a 6.2.6 DB with my customers DB to compare schema. I've found data in the collectiondefs table which doesn't exist in my 6.2.6 database, but does in my customer's DB, which started as a 5.2 database. What's odd is that the "builddate" in the table is 2006-03-31, which is the day we upgraded from 5.2 to 6.2.6. Am I correct in that:
1) The table was used with speedsearch in previous versions, and
2) it's not used now, and
3) I should be OK dropping it (I won't hold you to anything)
I know they're not using speedsearch, but I find it odd that the build date was 2006-03-31 in the table. I'm trying to figure out why it would have been updated if it's no longer used.
All the other "collectionxxxxx" tables are empty - I just found it odd the collectiondefs has values. Can anyone explain?
I have a few other tables that have data in them, but I'm not sure why. If anyone knows how they are/were used, feel free to share:
1) emailprofile (1 record)
2) ksync (They're not using KnowledgeSync)
3) ksync_rels (They're not using KnowledgeSync)
4) ksynctables (They're not using KnowledgeSync)
5) slxwebreport (They're not using web reporting, so this can probably go away)
6) useroption (Not to be confused with useroptionS. The record count is exactly the same as the slxwebreport table, making me think they're related.)
Thanks,
Jeff
|
|
As you well know, the problem w/dropping ANY SalesLogix original tables is that you must drop them via the SalesLogix db manager or you mess up (SalesLogix) meta-data
.. yes, you can drop the collectiondefs table under the above conditions.
The "k" tables are there because at some time "someone" installed the Scribe stuff.
In general, the rule is that SaLesLogix upgrades will NOT drop existing tables. The possibility is high they will break something (specifically FLS security). Only NEW OOTB blanks are in "stripped down" form.
--
rjl
|
|
|
|
Re: Some tables in the DB
Posted: 20 Mar 07 1:26 PM
|
fiogf49gjkf0d Originally posted by Bob (RJ)Ledger
As you well know, the problem w/dropping ANY SalesLogix original tables is that you must drop them via the SalesLogix db manager or you mess up (SalesLogix) meta-data
.. yes, you can drop the collectiondefs table under the above conditions.
|
|
I've discovered that there quite a few tables with entries in sectabledefs but not resynctabledefs and can't be dropped via DB manager. I ran SLXProfiler and found that dropping a table basically does this:
DROP TABLE <tablename>
DELETE FROM RESYNCTABLEDEFS WHERE TABLENAME = '<tablename>'
DELETE FROM SECTABLEDEFS WHERE TABLENAME = '<tablename>'
DELETE FROM JOINDATA WHERE FROMTABLE ='<tablename>' OR TOTABLE = '<tablename>'
DELETE FROM CALCULATEDFIELDDATA WHERE BASETABLE = '<tablename>'
I hadn't thought of calculatedfielddata but had basically figured out about resynctabledefs, sectabledefs and joindata. Can anyone think of any other updates or deletes that might not have shown up in the trace because the didn't apply to my test table?
Obviously using DB Manager is preferred but in this case it wasn't working.
Jeff
|
|
|
|
Re: Some tables in the DB
Posted: 21 Mar 07 8:41 AM
|
fiogf49gjkf0d The profiler does not show everything 
It's missing the blob manipulations in SecProfiles.. and THAT is messy stuff...IT's done in "hard code" so you do NOT see and SQL statements showing up in teh profiler.. In fact you HAVE to do it in "code".
--
rjl |
|
|
|
Re: Some tables in the DB
Posted: 21 Mar 07 11:56 AM
|
fiogf49gjkf0d Bob,
Wouldn't the blob manipulations show up as update statements to the database in SQL Profiler and/or the SLXProfiler? Otherwise the manipulations done in memory would never get written back out, effectively not changing anything.
I'm not doubting you, just not sure why a trace wouldn't show at least an update statement.
That said, any recommendations on how to drop the tables if "Delete Table" is disabled in Administrator? Should I insert a "fake" resynctabledefs record for those tables missing their record? I'm guessing that would enable the "Delete Table" option allowing the system to do it's thing when dropping the table.
Thanks for all your help!
Jeff
|
|
|
|
Re: Some tables in the DB
Posted: 22 Mar 07 8:45 AM
|
fiogf49gjkf0d Nope.. the blob manipulations do not show up.. It's not a simple Update... and it will look a bit "binary" if you do locate it.
As far as fixing tables.. it "depends"... this is an area that I specialize in (as a business . I tend to limit the info I post on this in any forum (business trade secrets).
--
rjl |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|