I use 3.xx version of litedb and want to shrink the file since it always grows its size.
I shrunk it using LiteDbExplorer's "shrink" button, but now app cannot use this db file.
But still it seems good when using viewer litedbexplorer, litedbviewer, litedbstudio.
I can see data well on these viewers.
but when run application then
it shows
message like "LiteDB.LiteException: Index not found on '<collection_name>._id',
at LiteDB.Query.Run(CollectionPage col, indexService indexer)
at
LiteDB.LiteEngine.<>c__displayClass14_0.b__0(Collectionpage col) ~~~..."
Did I make it broken?
but Index on _id(primary key) and other indexes still exist well.
I check it using "db.collectionname.indexes".
anybody help me through?
It was because of collections' name restriction.
If collection's name is not fit then it cannot manipulate itself, not only its documents.
And also LiteDBExplorer's shrinking function might have some problem.
It does not work always, but LiteDBshell works.
Please use "db.shrink" at shell.
I guess messages like "Invalid format: Collection" at shell can be fixed by changing collection's name.
Related
Years ago, I wrote a small app in itext2 to gather reports on a weekly basis and concatenate them into one PDF. The app used com.lowagie.text.pdf.PdfCopy to copy and merge the PDFs. And it worked fine. Performed exactly as expected.
A few weeks ago I looked into migrating the application to itex7. To that end, I used the copyPagesTo method of com.itextpdf.kernel.pdf.PdfDocument. When run on the same file set, this produces warnings like:
WARN PdfNameTree - Name "section.1" already exists in the name tree; old value will be replaced by the new one.
When I click on the link to "section.1" in the first document of the merged PDF, I am taken to "section.1" of the last document. Not what I expected and not what happens when using the itext2 app. In the PDF's produced by itext2, if I click on the link to "section.1" of the first document in the combined PDF, I am taken to section 1 of the first document.
There is a hint in Javadocs for copyPagesTo saying
If outlines destination names are the same in different documents, all
such outlines will lead to a single location in the resultant
document. In this case iText will log a warning. This can be avoided
by renaming destinations names in the source document.
There is however, no explanation of how this should be done. I find it odd that this should be necessary in itext7, although it wasn't in itext2.
Is there a simple way to get around his problem?
I've also tried the Sejda desktop app and it produces correct results, but I would prefer to automate the process through a batch script.
My guess is iText 2 didn't even know it might be a problem.
If iText can't deduplicate destination names, the procedure is roughly:
Follow /Catalog -> /Names -> /Dests in each document to find the destination name tree.
Deduplicate the names, by adding suffixes. Remember that a name with a suffix added might be equal to an existing name in the same or another document. Be careful!
Now you can rewrite the destination name trees. Since you have only used suffixes, you can do this in place - the lexicographic ordering of the names is unaltered so the search tree structure is not broken.
Now, rewrite destination links in each PDF for the new names. For example any dictionary entry with key /Dest, or any /D in a /GoTo action.
Now, after all this preprocessing, the files will merge without name clashes.
(I know all this because I've just implemented it for my own PDF software. It's slightly hairy stuff, but not intractable.)
If you like, I can provide a devel version of cpdf with this functionality, if you would like to test it.
I created a simple RME for TTeeGrid, a descendant perhaps of TGrid in Firemonkey. As shown below, the data are displayed at design time but not at runtime except the headers.
I've been breaking my head over this for weeks already but not luck.
Let me know if you need more details but what you see in the image are all you get.
I just need help to have the data displayed at runtime as shown in the design time.
UPDATE 1
This issue is not the case with TPrototypeBindSource. The data shown in the design time are displayed at runtime. Something is wrong somewhere.
I've never used the TeeGrid before, but the following worked fine
first time for me in Delphi Tokyo:
Download the TeeGrid trial from Steema.Com & install.
Create new multi-device app and place a TeeGrid and a FDMemTable on the form.
Load FDMemTable1 with the file Parts.Fds from the Delphi samples Data directory. Note, I did not then create any FieldDefs as I mentioned in my comment earlier as what I'm describing works without them.
Set the DataSource property of TeeGrid1 to FDMemTable1. TeeGrid1 immediately
creates columns for each of the Parts fields and populates them with data - see
screenshot below. I don't ordinarily include screenshots but in this case thought
I would as what I got was so clearly at odds with what you've reported.
Your TeeGrid etc are obviously more complicated than mine. so the best I can
suggest is that you backtrack to step 2 and see if you can replicate my result
with your data (either at design time or run time). It might be worth loading
your FDMemTable with some data at design time, as my impression is that live bindings
is less grief-prone when the datasource has some data.
Incidentally, fwiw the results of my own attempts to set up live bindings even with a regular TGrid have been rather patchy, until I discovered that instead of messing with the LB components myself, simply starting with a fresh TGrid, right-clicking on it and leaving the Live Bindings Wizard
to do its stuff consistently works fine.
I've been asked to look at C# code that's returning the following error:
Unable to cast object of type
'iTextSharp.text.html.simpleparser.IncCell' to type 'iTextSharp.text.Rectangle'.
at iTextSharp.text.pdf.PdfDocument.Add(IElement element)
at iTextSharp.text.Document.Add(IElement element)
It looks like they're using iTextSharp v5.0.2 and have not yet moved from HtmlWorker to XmlWorker.
Questions:
What is IncCell? I see it in the source docs but can't find any info about what it is - I'm assuming it's just for internal use.
Is this related to a cell in a table? A need for a Div or Paragraph within a cell?
What can they do to diagnose issues like this down to the HTML source that caused the error? I suspect this is an issue with not conforming to XHTML, but I can't verify that without knowing exactly what IElement that code was working on when it choked. It could be due to bad styling too, I have no idea at this time. Is there any kind of detail logging that will tell us what element is being processed at any given time? Should I just get them to load source and trace through it?
Is it probable that this will be fixed with an update to the latest version (currently 5.5.9), and a re-fit of XmlWorker?
Other recommendations?
Thanks!
I'm seeing some very strange behavior with FileMaker 14. I'm using LayoutObjectNames for some required functionality. On the development system it's working fine. It returns the list of named objects on the layout.
I close the file, zip it up and send it to the client, and that required functionality isn't working. He sends the file back and I open it and get a data viewer up. The function returns nothing. I go into layout mode and confirm that there are named objects on the layout.
The first time this happened and I tried recovering the file. In the recovered file it worked, so I assumed some corruption had happened on his end. I told him to trash the file I had given him and work with a new version I supplied. The problem came up again.
This morning he sent me the oldest version that the problem manifested in. I confirmed the problem, tried recovering it again, but this time it didn't fix the problem.
I'm at a loss. It works in the version I send him, doesn't on his system. We're both using FileMaker 14, although I'm using Advanced. My next step will be to work from a served file instead of a local one, but I have never seen this type of behavior in FileMaker. Has anyone seen anything similar? Any ideas on a fix? I'm almost ready to just scrap the file and build it again from scratch since we're not too far into the project.
Thanks, Chuck
There is a known issue with the Get (FileName) function when the file name contains dots (other that the one before the extension). I will amend my answer later with more details and a possible solution (I have to look it up).
Here's a quote from 2008:
This is a known issue. It affects not only the ValueListItems()
function, but any function that requires the file name. The solution
is to include the file extension explicitly in the file name. This
works even if you use Get (FileName) to return the file name
dynamically:
ValueListItems ( Get ( FileName ) & ".fp7" ; "MyValueList" )
Of course, this is not required if you take care not to use period
when naming your files.
http://fmforums.com/forums/topic/60368-fm-bug-with-valuelistitems-function/?do=findComment&comment=285448
Apparently the issue is still with us - I wonder if the solution is still the same (I cannot test this at the moment).
I'm using toLocalizedTime to output a date, as below
<span tal:content="python:here.toLocalisedTime(date.get('start_date'))"/>
This outputs eg. 2007/08/02, I'm just curious as to how one would alter the output so that it reads 02/08/2007
I'm not having much luck finding much info on toLocalizedTime, would someone point me in the right direction?
This depends on whether you have English selected as the site language (Site Setup >> Language). If so, then the default settings are used. You can change the defaults by dropping down into the ZMI, then into 'portal_properties', then 'site_properties'. The fields to change are either 'localTimeFormat' or 'localLongTimeFormat' depending on whether you pass in 'long_format=1' to the toLocalisedTime function.
If on the other hand, you have translations set up, the format may instead be pulled from the translation file for the locale selected. I'm not sure what is the easy way to change the format in this case (other than switching the site back to English). I guess you can register your own translation file but I've never needed to do that so you're going to have to look up the details.
Date string formatting follows the Python rules (http://docs.python.org/library/time.html#time.strftime).
Perhaps even more detail than you need:
here.toLocalizedTime()
is defined in the plone browser view at...
CMFPlone/browser/ploneview.py
which looks up the 'translation_service' utility, to call its 'ulocalized_time' function, defined at...
CMFPlone/TranslationServiceTool.py
which itself calls the 'ulocalized_time' function defined at...
CMFPlone/i18nl10n.py
As always, you can learn interesting things by grepping the source code ;-)
For an up to date answer for Plone 4.3 (after going through the source code)
These fields are now in the registry found at:
http://localhost:8080/yoursite/portal_registry
Then filter on "i18nl10n", which should give you the 4 fields you need to change.