Re: [firebird-support] Invoice Detail: Design / Normalization

[Hannes Streicher hstreic...@gmx.de [firebird-support]]

Guten Tag shg_siste...@yahoo.com.ar [firebird-support],


i do it that way, store all information in the Invoice,
because my experience is Data changes
changing your Item Description would change your Invoice which would get you in 
trouble with Tax Authorities
as an alternative you could "Version" your description and link to the correct 
Version

> It's a design / normalization question: How to save Invoice detail correctly?

> Each line on the invoice detail has its FK pointing to the Article's ID, but 
> sometimes the user needs to modify or add some text to the article 
> description just for that
> invoice. Or sometimes he/she needs to insert a "free" line (pointing to no 
> article at all) just filling the description.

> So my "big" doubt is: Is this a case for "denormalization" ? Should I add a 
> "description" field to the invoice detail (and 90% of the time having exactly 
> the same description of the article's table!!)

> Or should I have the "description" field in a separate table. In this case I 
> don't imagine how to update that table, as the user enters the data in a 
> DBGrid (I work with Delphi / IBDac)

> I hope I'm clear with my question!

> Thanks!


>   
>
>  
>


-- 
Mit freundlichen Grüssen
Hannes Streichermailto:hstreic...@gmx.de

Re: [firebird-support] Invoice Detail: Design / Normalization

[Arnold Levy arnoldjl...@gmail.com [firebird-support]]

When printing any document the normalisation issue comes up.

Personally I use a TMemo and write two lines to it. The first line
containing the field names - enclosed in " separated by ,. And the second
line containing the corresponding field values - once again enclosed in " -
all strings - separated by ,. Then I Memo1.SaveToFile () with a extension
.csv. This technique works great for running ms word mailmerge. The fields
are all those that appear once on every invoice.

For detail lines that are repeated - you need to automate word using
tables. This is off topic. I can help you with this if you email me.

Sincerely,

Arnold
Software Consultant.
On 23 Sep 2014 22:48, "shg_siste...@yahoo.com.ar [firebird-support]" <
firebird-support@yahoogroups.com> wrote:

>
>
> Hello, I've posted this question in the "general" but the moderator told
> me it's a "support" question. So here I go again!
>
> It's a design / normalization question: How to save Invoice detail
> correctly?
>
> Each line on the invoice detail has its FK pointing to the Article's ID,
> but sometimes the user needs to modify or add some text to the article
> description just for that invoice. Or sometimes he/she needs to insert a
> "free" line (pointing to no article at all) just filling the description.
>
> So my "big" doubt is: Is this a case for "denormalization" ? Should I add
> a "description" field to the invoice detail (and 90% of the time having
> exactly the same description of the article's table!!)
>
> Or should I have the "description" field in a separate table. In this case
> I don't imagine how to update that table, as the user enters the data in a
> DBGrid (I work with Delphi / IBDac)
>
> I hope I'm clear with my question!
>
> Thanks!
>
>
>  
>

Re: [firebird-support] Invoice Detail: Design / Normalization

[Fulvio Senore mail...@fsoft.it [firebird-support]]

Il 23/09/2014 22:48, shg_siste...@yahoo.com.ar [firebird-support] ha 
scritto:
>
>
> Hello, I've posted this question in the "general" but the moderator told
> me it's a "support" question. So here I go again!
>
> It's a design / normalization question: How to save Invoice detail
> correctly?
>
> Each line on the invoice detail has its FK pointing to the Article's ID,
> but sometimes the user needs to modify or add some text to the article
> description just for that invoice. Or sometimes he/she needs to insert a
> "free" line (pointing to no article at all) just filling the description.
>
> So my "big" doubt is: Is this a case for "denormalization" ? Should I
> add a "description" field to the invoice detail (and 90% of the time
> having exactly the same description of the article's table!!)
>
> Or should I have the "description" field in a separate table. In this
> case I don't imagine how to update that table, as the user enters the
> data in a DBGrid (I work with Delp hi / IBDac)
>
> I hope I'm clear with my question!
>
> Thanks!
>

I keep a "description" column in the invoice details. If the user 
chooses an article I copy the article's description. If the user wants a 
free line he can simply write what he wants.

There is another reason for doing things in this way: if you print again 
the invoice at a later time the printed output must be the same ad 
before. If the users change the article's description the description in 
the invoice must not change, so you need an autonomous description in 
the invoice.

Fulvio Senore

[firebird-support] Firebird, DBA, and UPS Worldship connection issues

[Michael Young micha...@waterstoneco.com [firebird-support]]

Hello All,
We are a small manufacturing company and use a ERP system called DBA that is 
supported by a Firebird database.


I wanted to use the bar code feature in DBA and add that to our packing slips, 
with the goal of scanning the sales order information directly from DBA to UPS 
worldship.
There is no writing back to the Firebird database, this is only to extract data.


I can successfully scan one bar code, but not any other ones. It seems to lose 
the connection to the database but I cant figure out why?
I contacted UPS and we retested the UPS setting and its working.
I also contacted DBA ERP support but this is a bit out of there scope.


Does anyone have any previous experience in dealing with this issue or a 
similar one?


Any help would be appreciated.


Regards,


Michael Young


Materials Manager
Waterstone Faucets
41180 Raintree Ct.
Murrieta, CA 92562
Toll free, 888-304-0660
951-304-0520
Fax: 951-304-0525
Designed,Machined,Finished in the USA.
[waterstone-faucet-logo200]










[Non-text portions of this message have been removed]

[firebird-support] Invoice Detail: Design / Normalization

[shg_siste...@yahoo.com.ar [firebird-support]]

Hello, I've posted this question in the "general" but the moderator told me 
it's a "support" question. So here I go again!

It's a design / normalization question: How to save Invoice detail correctly? 

Each line on the invoice detail has its FK pointing to the Article's ID, but 
sometimes the user needs to modify or add some text to the article description 
just for that invoice. Or sometimes he/she needs to insert a "free" line 
(pointing to no article at all) just filling the description.

So my "big" doubt is: Is this a case for "denormalization" ? Should I add a 
"description" field to the invoice detail (and 90% of the time having exactly 
the same description of the article's table!!)

Or should I have the "description" field in a separate table. In this case I 
don't imagine how to update that table, as the user enters the data in a DBGrid 
(I work with Delphi / IBDac)

I hope I'm clear with my question!

Thanks! 

Re: [firebird-support] Firebird Embedded corruptions

[Ann Harrison aharri...@ibphoenix.com [firebird-support]]

On Tue, Sep 23, 2014 at 10:49 AM, Jan Flyborg jan.pers...@gmail.com
[firebird-support]  wrote:

>
>
> The first was a wrong page type, which sounds like a bug that was fixed in
>> a newer version in code that's common to all Firebird architectures.  In
>> your case, the bad page was in an index (7).  If you can find the index
>> with the bad page and recreate it, all will be well.
>>
>> That sounds very good and it seems like an upgrade to 2.5.3 will make
> sure that we do not see this again.
>

Anytime your users get an error of of the form "wrong page type, expected 7
encountered n", you can probably work with them to identify and rebuild the
bad index.

>
>
>>
>> The second problem (CCH_precedence: block marked.  file: cch.cpp line:
>> 4390) is more concerning
>>
> If that is of any help for you, I was wrong in my original posting when I
> said we were using 2.5.1 (I mean that the line numbers in the exception
> might lead you to draw the wrong conclusion when I gave you the wrong
> version). We are currently using 2.5.2 and nothing else.
>

I follow bug reports but not religiously.  So I searched for one that
includes "block marked" and "modify RDB$INDICES" and found #4467 which is
marked as "will not fix" and described as a user error.  User errors should
not cause internal cache manager problems, so I'm somewhat bemused.  It was
reported in 2.5.2, so it may well be your problem.

>
>
>
>> The third problem is two records in a referencing table lack mates in the
>> referenced table, despite a referential constraint.  I have no idea how
>> that happened, but it should be reasonably easy to fix in your database.
>>
>
> In another posting (later than yours) Fabiano is saying that these errors
> are connected to bad memory chips and in the future we will instruct our
> users who are having this problem to run memtest86 overnight to check that
> the memory is physically OK. These constraints problems are actually the
> most common that we see.
>

Clever memory problem to corrupt just the key or the constraint check.
Certainly it's worth checking that the memory is OK.  I'd also check that
the referencing key looks generally sound.  Do you add referential
constraints to existing databases?  A problem with broken constraints is
that the error doesn't leave traces, so a reproducible case would be very
helpful, but very hard to produce.

>
>
>>
>> Gfix is pretty old and somewhat crude.  IBFirstAid might give you better
>> help on physical corruptions.  Checking that there is no non-conforming
>> data before creating constraints may help with logical corruption.
>>
>
> Yes that would probably be a better choice for us, but we cannot bundle
> IBFirstAId togethe r with our application. Will however download it and
> try it on files to got sent to us.
>

The analysis tool is free - maybe your users could download it themselves
to look for evidence.  But it's not going to help with broken referential
constraints or mangled cache precedence.

>
>
> Another thing, what do you say about the posting above where the theory is
> that Volume Shadow Copy is interfering with the database? Have you heard
> about that before?
>

I'm quite sure that Volume Shadow Copy won't make good copies of an active
database or any other file that's open for random writes.  Whether it could
corrupt the original is an open question.  Lots of people claim to have
seen instances where copying a database corrupts the original.

>
> And another last comment. We have bundled Firebird w ith very many
> installations of our product and it might be the case that what we are
> seeing are very rare problems, that no one else has experienced before. Do
> you think we should post bug reports every time we see an exception or a
> problem that you have not already been made aware of?
>

Search the tracker (http://tracker.firebirdsql.org/browse) first to see if
the problem has been reported.  Then you might mention it on the support
list to see if there's something that looks like a user error so you won't
annoy the developers with stuff that the volunteers on this list could
resolve.  But if your getting errors with source file and line numbers, the
chances are good that you've found a bug.  Firebird is used pretty widely
and quite heavily in many installations.  However, the embedded form
probably gets less stress in the world than any of the architectures, so
you may be stressing something unusual.   No development group, open or
closed source, can fix bugs it doesn't know about.

Thank you for working with Firebird on these problems.

Good luck,

Ann

Re: [firebird-support] Firebird Embedded corruptions

[Alexey Kovyazin a...@ib-aid.com [firebird-support]]

Jan,

 >Yes that would probably be a better choice for us, but we cannot 
bundle IBFirstAId together with our application. Will however download 
it and try >it on files to got sent to us.

Actually, current version of FirstAID which is available at our web site 
is a full version, but it requests license every time you are running 
recovery (not diagnose).
  So you can (from license and technical points of view) include 
FirstAID executables into your application, so user will be able to use 
on demand.
Don't hesitate to contact our supp...@ib-aid.com for more details.

Regards,
Alexey Kovyazin
IBSurgeon








++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ 

++


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

RE: [firebird-support] Firebird Embedded corruptions

[Marcos Herrera marcos.herr...@manar.com.co [firebird-support]]

Hi Dear Friends



I could resolve the issue, I copied the DLL in my machine and create an
alias in aliases.conf



Thanks for all



-- 

Cordialmente,



*Marcos Andrés Herrera Niño*

marcos.herr...@manar.com.co

Director Campus Manar

www.manar.com.co

Tel. (57 1) 486 6610

Cel. (57 321) 439 0681

Carrera 5 No. 69-14

Oficina 301

Bogotá D.C. 110221

Colombia

[image: Descripción: Descripción: Descripción: Descripción: Facebook]

 [image: Descripción: Descripción: Descripción: Descripción: Twt]


[image: Descripción: Descripción: Descripción: Descripción: Manar]
[image: Descripción: Descripción: Descripción: Descripción:
cid:image006.jpg@01CF3701.C405C080]





*De:* firebird-support@yahoogroups.com [mailto:
firebird-support@yahoogroups.com]
*Enviado el:* martes, 23 de septiembre de 2014 09:50 a.m.
*Para:* firebird-support@yahoogroups.com
*Asunto:* Re: [firebird-support] Firebird Embedded corruptions





Hi,

Thanks for this and sorry for my slow response. Please see my comments
below.

Best Regards

//Jan Flyborg



2014-09-19 21:13 GMT+02:00 Ann Harrison aharri...@ibphoenix.com
[firebird-support] :



On Mon, Sep 15, 2014 at 7:41 AM, Jan Flyborg jan.pers...@gmail.com
[firebird-support]  wrote:







I just made another posting where I tried to describe three different
examples of things we have seen.



The first was a wrong page type, which sounds like a bug that was fixed in
a newer version in code that's common to all Firebird architectures.  In
your case, the bad page was in an index (7).  If you can find the index
with the bad page and recreate it, all will be well.



Just as an FYI, the page types are:

 0 -   undefined, normally an uninitialized page and indicates a
bad page pointer elsewhere;

 1 -  Database header page

 2 - Page inventory page

 3 - Transaction inventory page

 4 - Pointer page

 5 - Data page

 6 - Index root page - contains information about each index on the
table, one per table

 7 - Index (B-tree) page

 8 - Blob data page

 9 -   Generator pages



That sounds very good and it seems like an upgrade to 2.5.3 will make sure
that we do not see this again.





The second problem (CCH_precedence: block marked.  file: cch.cpp line:
4390) is more concerning - I don't remember having read a bug about it.
CCH is the cache handler.  A "mark" is the sign that a page is about to be
changed.   When Firebird is forced to write a page either as part of a
commit or to free space in the cache, it must write out any pages that the
page depends on first.  That's a little obscure.  Suppose that the page
you're about to write has a record with a back version, and the back
version is on a different page.  To keep the database consistent, the page
with the back version must be on disk before the page that includes a
record that points to the back version.  Firebird keeps a list of
precedence relationships and CCH goes through them before writing a page.
I think the error means that someone is currently writing  to a page that's
on the precedence list.  That should never happen.  It's interesting that
the problem occurred during an alter index operation.  However, the
database should be fine on disk and usable after you restart Firebird.
Page marks are entirely in memory.  It's quite possible that I missed a bug
report and this problem was fixed in a later version.





If that is of any help for you, I was wrong in my original posting when I
said we were using 2.5.1 (I mean that the line numbers in the exception
might lead you to draw the wrong conclusion when I gave you the wrong
version). We are currently using 2.5.2 and nothing else.




The third problem is two records in a referencing table lack mates in the
referenced table, despite a referential constraint.  I have no idea how
that happened, but it should be reasonably easy to fix in your database.



In another posting (later than yours) Fabiano is saying that these errors
are connected to bad memory chips and in the future we will instruct our
users who are having this problem to run memtest86 overnight to check that
the memory is physically OK. These constraints problems are actually the
most common that we see.





The first problem is what I would call a physical  corruption - the
internal structure of the database is corrupt.  The second is an in-memory
  corruption - the disk database is OK, but the in-memory version is
damaged.  The third is logical corruption - the database is physically
intact, but does not conform to the data rules..





Typically we fix our problems with a gfix -mend and then doing a backup
restore cycle. Usually some tables then still have problems (typically
foreign keys that refers to non existing primary keys), so if possible we
then remove the faulty records and then it works again.



Problem is tha

Re: [firebird-support] Firebird Embedded corruptions

[Jan Flyborg jan.pers...@gmail.com [firebird-support]]

Hi,

Thanks for this and sorry for my slow response. Please see my comments
below.

Best Regards
//Jan Flyborg

2014-09-19 21:13 GMT+02:00 Ann Harrison aharri...@ibphoenix.com
[firebird-support]
:

>
>
> On Mon, Sep 15, 2014 at 7:41 AM, Jan Flyborg jan.pers...@gmail.com
> [firebird-support]  wrote:
>
>>
>>
>>
>> I just made another posting where I tried to describe three different
>> examples of things we have seen.
>>
>
> The first was a wrong page type, which sounds like a bug that was fixed in
> a newer version in code that's common to all Firebird architectures.  In
> your case, the bad page was in an index (7).  If you can find the index
> with the bad page and recreate it, all will be well.
>
> Just as an FYI, the page types are:
>  0 -   undefined, normally an uninitialized page and indicates a
> bad page pointer elsewhere;
>  1 -  Database header page
>  2 - Page inventory page
>  3 - Transaction inventory page
>  4 - Pointer page
>  5 - Data page
>  6 - Index root page - contains information about each index on the
> table, one per table
>  7 - Index (B-tree) page
>  8 - Blob data page
>  9 -   Generator pages
>

That sounds very good and it seems like an upgrade to 2.5.3 will make sure
that we do not see this again.


>
> The second problem (CCH_precedence: block marked.  file: cch.cpp line:
> 4390) is more concerning - I don't remember having read a bug about it.
> CCH is the cache handler.  A "mark" is the sign that a page is about to be
> changed.   When Firebird is forced to write a page either as part of a
> commit or to free space in the cache, it must write out any pages that the
> page depends on first.  That's a little obscure.  Suppose that the page
> you're about to write has a record with a back version, and the back
> version is on a different page.  To keep the database consistent, the page
> with the back version must be on disk before the page that includes a
> record that points to the back version.  Firebird keeps a list of
> precedence relationships and CCH goes through them before writing a page.
> I think the error means that someone is currently writing  to a page that's
> on the precedence list.  That should never happen.  It's interesting that
> the problem occurred during an alter index operation.  However, the
> database should be fine on disk and usable after you restart Firebird.
> Page marks are entirely in memory.  It's quite possible that I missed a bug
> report and this problem was fixed in a later version.
>
>
If that is of any help for you, I was wrong in my original posting when I
said we were using 2.5.1 (I mean that the line numbers in the exception
might lead you to draw the wrong conclusion when I gave you the wrong
version). We are currently using 2.5.2 and nothing else.



> The third problem is two records in a referencing table lack mates in the
> referenced table, despite a referential constraint.  I have no idea how
> that happened, but it should be reasonably easy to fix in your database.
>

In another posting (later than yours) Fabiano is saying that these errors
are connected to bad memory chips and in the future we will instruct our
users who are having this problem to run memtest86 overnight to check that
the memory is physically OK. These constraints problems are actually the
most common that we see.


>
>
The first problem is what I would call a physical  corruption - the
> internal structure of the database is corrupt.  The second is an in-memory
>   corruption - the disk database is OK, but the in-memory version is
> damaged.  The third is logical corruption - the database is physically
> intact, but does not conform to the data rules..
>
>
>
>> Typically we fix our problems with a gfix -mend and then doing a backup
>> restore cycle. Usually some tables then still have problems (typically
>> foreign keys that refers to non existing primary keys), so if possible we
>> then remove the faulty records and then it works again.
>>
>
Problem is that these are not my databases. I have normally no access to
them since they are running in a standalone installation at our customers
sites. Recently we have bundled our own homemade tool for repairing
databases that our customer can use when they are experiencing problems
(basically a graphical frontend for gfix), but sometimes this is not enough
and the databases has to be sent to us.


>
> Gfix is pretty old and somewhat crude.  IBFirstAid might give you better
> help on physical corruptions.  Checking that there is no non-conforming
> data before creating constraints may help with logical corruption.
>

Yes that would probably be a better choice for us, but we cannot bundle
IBFirstAId together with our application. Will however download it and try
it on files to got sent to us.


>
> Good luck (and my apologies for the late response)
>
>
No need for any apologies. I am very grateful for you taking your time to
help us.

Another thing, what do you say ab

Re: [firebird-support] Re: How to populate a new table column with a INTEGER sequence?

[duque.herna...@yahoo.com [firebird-support]]

 Yes Martijn you are quite rigth, exactly what I wanted to do ...
 

 Thank you,
 

 Hernando.