Client\Supplier Contact Details [closed] - sql-server-2005

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I was wondering what would be the best way to store contact details of supplier and clients.
What I was thinking was that there would be
GUID, ParentGUID,Type,TypeDesc,Details
The type would be a integer,typedesc would be for cases such as others and the details would obviously be the data.
the problem that I am finding is how to have this all linked.
This being that A client -> Contact(Title, Name,Middle,Surname) -> Phone -> Alias
This could be a hierarchy case.
As of now Supplier and Client tables cannot be joined due to backward compatibility. But will be done in the future.
Also due to certain client limitations MSSQL 2005 must be assumed as otherwise there wouldn't be a problem as this was solved in 2008 with getroot() and other useful functions.
I would have probably many cases where I would search on one of the fields. And require to know the client or supplier.

I eventually used recursive CTE for retrieving the data

Related

Is sharing the same database between two programming languages possible? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 days ago.
Improve this question
Program A is good at collecting data while Program B, in another language, is good at creating REST APIs. Is it possible to connect these two with a single database that A and B will read and write to? Performance for database operations is not really an issue in my case.
Sure this is possible. Databases typically can handle multiple connections from different programs/clients. A database does not really care which language the tool that is making the connection is written in.
Short edit:
Also most databases support "transactions". Which are used to cover that different connected clients do not break consistency of your application data while reading and writing in parallel.

(Quickbooks Online) Triggering Fields to Autopopulate via the API [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I'm creating invoice records via the Quickbooks API, which is working fine. But, certain fields that autopopulate in the UI, are not populating when creating via the API (For instance the Invoice # / DocNumber). Any thoughts on how to force those fields to autopopulate when using the API?
Note: Someone marked this question as unclear. No idea how an exact question can be made any clearer.
Partially figured this one out. The DocNumber needs the AutoDocNumber field set to true. Still a few other fields that are not auto populating, though.
The other fields I just decided to pull from the customer record, since they exist there as well.

SQL - best practices [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am about to develop a small cms\forum. Multiple customers are going to have there own access where the customers can communicate white them.
What is best practices- to make separate SQL db to each customer's cms data or one big to contain all the customers data?
As I cannot comment, so I can only type here.
It is strange that you would like to have separate database for each customer and it seems impossible to manage multiple db for just one purpose or function. For example, how could you identify which db belong to which customer? Also, do you expect to have many resource to allocate to each customer? a db simply waste if the customer is not active.
So, I suggest you to use one db to manage all the customers data which is normal solution.

How Users can call a SAP module, should they Log in? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I have created an SAP module for online recrutement exams that requires from candidates to log in to take their exams .. everything works fine but I have no idea how to do the "log in" part where users can log in and take their exams directly. Do I have to create SAP accounts for them or what exactly ?
I am totally a beginner, thank you for your help.
You're not even telling us what UI technology you chose - but basically, unless you want to explicitly violate licensing agreements, you need a named SAP user for every business user.

sql database convention [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Apologies in advance if this is a stupid question. I've more or less just started learning how to use SQL.
I'm making a website, the website stores main accounts, each having many sub-accounts associated with them. Each sub-account has a few thousand records in various tables associated with it.
My question is to do with the conventional usage of databases. Is it better to use a database per main account with everything associated with it stored in the same place, store everything in one database, or an amalgamation of both?
Some insight would be much appreciated.
Will you need to access more than one of these databases at the same time? If so put them all in one. You will not like the amount of effort and cost 'joining' them back together to do a query. On top of that, every database you have needs to be managed, and should you need to transfer data between them that can get painful as well.
Segregating data by database is a last resort.